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Prefazione 



Ho conosciuto Massimo Carli nel 20 10, quando stavo organizzando la prima conferenza italiana 
sullo sviluppo per dispositivi mobili. A quell'epoca, trovare qualcuno competente sulla 
programmazione per Andro id e al tempo stesso capace di spiegarne i concetti più avanzati non era 
un'impresa facile, eppure Massimo aveva già alle spalle un libro su questi temi, il primo in italiano. 
Inutile dirvi che la sua sessione fu un successo! 

Scorrendo questa sua nuova opera, ho notato con piacere la presenza di diversi approfondimenti 
che affrontano, fin nel nocciolo, aspetti spesso trascurati da altri testi o a cui viene "lasciata al lettore 
la soluzione del problema". Sto parlando, per esempio, di come gestire al meglio la diversificazione 
della piattaforma Android, caratteristica fondamentale alla base del suo grande successo, ma che 
impone a designer e sviluppatori di ragionare in un determinato modo fin dalla creazione del primo 
mockup. Oppure la laboriosa implementazione di un syncAdapter, le varie opzioni per la gestione del 
multithreading e altri aspetti 

Insomma, a mio avviso quello che Massimo maggiormente ha saputo raccogliere nelle successive 
pagine è stata la sua profonda conoscenza della piattaforma Android, maturata sul campo dopo tanti 
anni di lavoro quotidiano. La merce più rara che imo sviluppatore alle prime armi possa trovare. 

Alfredo Morresi 

Alfredo Morresi, classe 1979, è un amante della natura e della tecnologia, sostenitore del free 
software e delle corse lungo la spiaggia. Da tempo immemore lavora come sviluppatore su diverse 
tecnologie, l'ultima delle quali è stata appunto la piattaforma Android. Da un anno circa, inoltre, cerca 
di prendersi cura degli sviluppatori italiani orientati alle tecnologie Google. 
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Introduzione 



No questions... no answers... 
Men in Black III, 2012 

Negli ultimi anni, Andro id si è affermata come una delle principali piattaforme per lo sviluppo di 
applicazioni mobili, dividendosi quasi tutto il mercato con Formai acerrimo rivale iOS di Apple. 
Sebbene le due piattaforme si rincorrano dal punto divista delle funzionalità, si differenziano 
sicuramente dal punto di vista di quella che si chiama apertura, o meglio con il concetto di open. 
Mentre la piattaforma di Apple è chiusa (non personalizzabile), il produttore è unico e le tipologie di 
dispositivi sono in numero limitato, Andro id rappresenta la collezione di un numero elevatissimo di 
versioni diverse su dispositivi diversi realizzati da vendor diversi Potremmo discutere per centinaia di 
pagine su vantaggi e svantaggi di queste due filosofie; sicuramente quello che stiamo vedendo è un 
proliferare di specializzazioni di Android, culminata proprio in questi giorni (siamo a inizio aprile 2013) 
daU'ufficializzazione della piattaforma Facebook Home. Si tratta infatti, a grandi linee, di 
un'applicazione personalizzata di Home la quale permette l'avvio delle normali applicazioni Android 
oltre che l'accesso a funzionalità caratteristiche del social network Facebook. 

Indipendentemente da cosa e da come la si pensi, Android rappresenta sicuramente una 
piattaforma che lo sviluppatore, professionista o meno, deve imparare a conoscere per non rimanere 
indietro nello sviluppo delle applicazioni mobili, e questo è l'obiettivo del presente testo. 

A differenza delle versioni precedenti, ho deciso di seguire un approccio completamente diverso. 
Sebbene io rimanga sempre dell'opinione che "i fondamenti sono fondamentali" e che gli aspetti 
teorici siano necessari alla comprensione di un linguaggio o piattaforma, ho deciso di cambiare e 
seguire un metodo molto pratico che porterà il lettore, passo dopo passo, alla realizzazione di 
un'applicazione che abbiamo chiamato UGHO (User Generateci HOroscope) e che sarà un ottimo 
pretesto per affrontare la maggior parte degli aspetti relativi allo sviluppo di un'applicazione Android. 

Il Capitolo 1 ci permetterà di scaldare i motori e prepararci a partire affrontando tutti i concetti che 
sono necessari allo sviluppo con questa piattaforma. Vedremo quindi che cos'è Android, che 
relazione ha con Java e descriveremo i principi fondamentali di questo linguaggio. Non sarà un 
manuale di Java ma una descrizione, molto pragmatica, di quello che ci sarà utile successivamente 
nella creazione delle applicazioni. In particolare vedremo che cos'è un package e i principali concetti 
diobject orientation. Ci occuperemo quindi del delegation model, ovvero del meccanismo alla 
base della gestione degli eventi, di inner class e quindi di generics. L'obiettivo di questo nostro primo 
capitolo, che gli esperti Java potranno eventualmente saltare nella prima parte, è quello di preparare il 
lettore al viaggio verso la realizzazione di UGHO che, oltre che essere un'applicazione Android, sarà 
anche qualcosa di divertente. 

Il Capitolo 2 è dedicato all'installazione di Android Studio, ovvero dell'IDE che andremo a 
utilizzare per lo sviluppo. La procedura di installazione è qualcosa su cui Google interviene spesso; 
nelle precedenti versioni del testo ho dovuto modificare questa parte un numero incredibile di volte. 
Per questo motivo, la vedremo molto velocemente, rimandando alla documentazione ufficiale per i 
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dettagli Al termine di questo capitolo avremo capito come creare un progetto e come utilizzare il tool 
dibuild che si chiama Gradle. 

Nel Capitolo 3 iniziamo a tare sul serio, affrontando quelli che sono i concetti di base di ogni 
applicazione Android. Con il pretesto di creare il flusso di navigazione diUGHO vedremo infatti che 
cosa sono le activity e come questi componenti collaborano tra loro per la visualizzazione delle 
schermate e il passaggio da una all'altra. Vedremo che cosa sono le risorse e come queste possono 
essere utilizzate per gestire un numero sempre maggiore di dispositivi diversi attraverso il concetto di 
qualificatore. Affronteremo quindi il concetto di task e creeremo i primi layout, di cui impareremo a 
gestire le preview attraverso l'apposito tool di Android Studio. Per quello che riguarda le activity, 
vedremo nel dettaglio il loro ciclo di vita per poi dedicarci allo studio di un altro concetto 
fondamentale in Android, ovvero gfiintent insieme agli intent filter. Si tratterà del capitolo più 
importante e impegnativo del libro, che ci metterà però nelle condizioni di scrivere già alcune 
applicazioni anche se semplici 

In precedenza abbiamo accennato all'annoso problema di Android che per alcuni è invece una sua 
caratteristica vincente, ovvero la possibilità di essere eseguito su dispositivi molto diversi tra loro 
come caratteristiche e soprattutto come dimensioni del display. Il caso tipico è dato dalla possibilità di 
creare applicazioni che in altri ambiti si dicono universali, cioè eseguibili sia su smartphone sia su 
tablet sfruttando le caratteristiche di ognuno attraverso l'utilizzo di opportuni layout. Il Capitolo 4 è 
proprio dedicato a questo, e tratta il concetto fondamentale difragment come componente 
riutilizzabile di un'interfaccia grafica. 

I Capitoli 5 e 6 sono un approfondimento di che cos'è una view, un viewGroup e in particolare 
come si utilizzano le Listview come elemento fondamentale di ogni layout. In particolare vedremo nel 
dettaglio che cos'è un adapter e quali sono le implementazioni messe a disposizione dall'SDK. 
Vedremo anche come realizzare un componente personalizzato relativamente complesso utilizzando 
sia un approccio che abbiamo definito di alto livello (come composizione di altri esistenti) sia uno di 
basso livello (uso di strumenti di disegno su Canvas). Nello specifico realizzeremo un calendario da 
utilizzare all'interno di un layout o come finestra di dialogo. 

II Capitolo 7 è invece dedicato a un componente molto importante in quanto presente in tutti i 
pattern UI suggeriti da Google, ovvero l'ActionBar. Si tratta di un componente disponibile solamente 
dalla versione 3.0 della piattaforma che richiede una libreria di terze parti di nome 
ActionBarSherlock (ABS) per poter essere utilizzato con le versioni precedenti In questo capitolo 
vedremo come utilizzare l'ActionBar standard o come integrare il framework ABS in Android Studio 
e come utilizzarlo. 

Il Capitolo 8 è di fondamentale importanza in quanto tratta tutti gli strumenti che Android ci mette a 
disposizione per la gestione della persistenza. Descriveremo inizialmente come si gestiscono le 
SharedPropert ies fino alla realizzazione di un'interfaccia personalizzabile dei Settings 
dell'applicazione. Dopo una veloce descrizione di come vengano gestiti i file, vedremo come sia 
possibile interagire con un database relazionale e più precisamente SQLite. Descriveremo non solo le 
principali classi ma soprattutto i principali pattern di utilizzo, compresi quelli che riguardano una 
possibile personalizzazione delcursor. Concluderemo questo fondamentale capitolo conia 
descrizione e realizzazione di un content provider, che vedremo essere molto importante anche in 
relazione alle funzioni di gestione degli account, oltre ad avere un ruolo cruciale anche nel meccanismo 
di intent resolution. 

Come avremo occasione di sottolineare più volte, la realizzazione di un'applicazione che risponde 
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in modo reattivo alle azioni dell'utente è una priorità assoluta. È quindi fondamentale padroneggiare 
tutti i meccanismi di gestione asincrona delle operazioni e in particolare saper gestire il multithreading. 
Il Capitolo 9 è dedicato a tutti i meccanismi alla base dei processi e dei servizi Dopo un'introduzione 
sul concetto di thread e task, descriveremo nel dettaglio cosa sono gli handler e i looper in relazione 
ai possibili scenari di interazione con il thread principale di gestione della UI. Da qui vedremo cos'è 
un AsyncTask e come utilizzarlo in contesti diversi. La seconda parte del capitolo è quindi dedicata a 
un insieme di strumenti che hanno subito vari miglioramenti nelle ultime versioni, ovvero le notifiche; 
ci dedicheremo poi alla descrizione dei componenti che, insieme alle activity, hanno assunto sempre 
più importanza in tutte le architetture Androidi i service. A tale proposito realizzeremo due importanti 
esempi di utilizzo di un servizio nelle due modalità: Started e Bound. Descriveremo infine l'utilizzo di 
un intent service che sarà utile in diversi casi, come vedremo negli ultimi capitoli 

Il Capitolo 10 è dedicato a due argomenti di fondamentale importanza, ovvero la sicurezza e il 
networking. Dopo una descrizione di quello che è il Security Model di Android, vedremo come 
eseguire delle richieste HTTP sia attraverso il classico meccanismo che utilizza l'Httpciient di 
Apache sia attraverso il nuovo framework di nome Volley, che impareremo a integrare all'interno di 
Android Studio. 

I Capitoli 1 1 e 12 sono dedicati a due argomenti in un certo senso slegati dal resto ma che 
permettono di arricchire le applicazioni di due funzionalità di effètto, ovvero le animazioni e iwidget. 
Per quello che riguarda le animazioni descriveremo sia la modalità classica sia quella che utilizza il 
nuovo framework chiamato Property Animator. Per quello che riguarda i widget, ci occuperemo sia 
della semplice visualizzazione di un'informazione nella Home del dispositivo sia della visualizzazione di 
un insieme più complesso di informazioni all'interno di un content provider. Concluderemo il capitolo 
descrivendo come sia possibile, nelle ultime versioni di Android, creare dei widget da inserire nella 
schermata dilock del dispositivo, ovvero quella che solitamente ospita l'orologio. 

II Capitolo 13 tratta un argomento che di questi tempi sta assumendo un'importanza sempre 
maggiore, ovvero la gestione degli account e della sincronizzazione. Nella prima parte vedremo come 
funziona il sistema basato suU'utilizzo della classe AccountManager per la gestione degli account. 
Vedremo anche come creare un account per la nostra applicazione UGHO utilizzando l'SDK di 
Facebook, sfruttandone i sistemi di autenticazione e soprattutto le informazioni in esso contenute. 
Concluderemo quindi il capitolo affrontando il problema della sincronizzazione delle informazioni di un 
content provider con altrettante remote attraverso la definizione di un syncAdapter. 

L'ultimo capitolo del testo, il 14, tratta un argomento molto interessante che ci ha permesso di 
introdurre i Google Play Services annunciati all'ultima Google IO del 2013, ovvero le Google Maps 
v2.0. In questo capitolo impareremo a importare queste API e a utilizzarle per la realizzazione di 
un'applicazione che ci permetta di gestire quelli che si chiamano Geofence, che altro non sono che 
zone per le quali il LocationManager genera degli eventi in occasione dell'ingresso o uscita dalle 
stesse. Nello stesso capitolo accenneremo all'utilizzo della funzionalità chiamata activity recognition 
per determinare non la posizione del dispositivo ma la modalità di spostamento. Vedremo infatti come 
capire se l'utente sta camminando, correndo oppure utilizzando un altro mezzo durante i propri 
spostamenti 

Come è facile intuire si tratta di un testo con molti concetti e soprattutto numerosi esempi 
contestualizzati alla realizzazione dell'applicazione UGHO che, è bene precisare, non rappresenta un 
prodotto finito ma contiene diversi punti di personalizzazione che possono essere riutilizzati in altri 
progetti 
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Capitolo 1 



Android e Java per Android 



Come accennato nell'Introduzione, il primo capitolo è dedicato alla preparazione di tutto ciò che ci 
serve per sviluppare la nostra applicazione, che illustreremo nel dettaglio più avanti. Dedichiamo 
quindi queste prime pagine a una descrizione molto veloce di cosa sia Android e di quale sia la sua 
relazione con il linguaggio di programmazione Java, che sarà quindi l'argomento della seconda parte. 
Rispetto ai volumi precedenti ho deciso infatti di riprendere alcuni concetti della programmazione Java 
più volte richiesti dai lettori (solo quello che serve al nostro scopo). Ciò che daremo per quasi 
scontato saranno i concetti di programmazione ad oggetti. Se il lettore si sente già a suo agio con il 
linguaggio potrà leggere solamente la prima parte e quindi andare direttamente al capitolo successivo. 
Per iniziare descriveremo la classica applicazione Hello worid, che nasconde un numero elevatissimo 
di concetti che rappresentano spesso uno scoglio iniziale con il linguaggio. Vedremo poi che cosa è il 
delegation model e come si utilizza in ambiente Android e mobile in generale. A tale proposito 
parleremo di classi inteme. Concluderemo quindi con la descrizione dei generics. 

Disolito il primo capitolo di un libro di questo tipo descrive anche l'installazione dell'ambiente. Qui 
abbiamo deciso di rimandare al capitolo successivo per due ragioni principali La prima riguarda il 
latto che proprio in questi giorni è stato presentato alla Google IO un nuovo tool di sviluppo che si 
chiama Android Studio basato su IntelliJ. Il secondo motivo è invece legato all'elevata volatilità della 
procedura di installazione, che cambia di continuo. Per questa daremo il riferimento della 
documentazione ufficiale. 

Cos'è Android 

È molto probabile che un lettore che ha acquistato questo testo sia già a conoscenza di cosa sia 
Android. Dedichiamo quindi queste poche righe a chiarire alcuni aspetti importanti. Innanzitutto 
Android non è un linguaggio di programmazione né un browser ma un vero e proprio stack che 
comprende componenti che vanno dal sistema operativo fino a una virtual machine, che si chiama 
Dalvik, per l'esecuzione delle applicazioni Caratteristica fondamentale di tutto ciò è l'utilizzo di 
tecnologie open source a partire dal sistema operativo che è Linux con il kernel 2.6, fino alla specifica 
virtual machine. Il tutto è guidato daW Open Handset Alliance (OHA), un gruppo di una cinquantina 
di aziende (numero in continua crescita), il cui compito è quello di studiare un ambiente evoluto per la 
realizzazione di applicazioni mobili 

Architettura di Android 

Quando si introduce Android si utilizza sempre la famosa immagine mostrata nella Figura 1 . 1 che 
ne descrive l'architettura. In questa sede non ci dilungheremo nella spiegazione di ciascuno dei 
componenti raffigurati ma utilizzeremo l'immagine per inquadrare quello che è l'elemento forse più 
importante per noi sviluppatori, ossia la Dalvik VM. Notiamo come essa faccia parte dell'ambiente di 
runtime e sia costruita sui servizi offerti dal kernel e dalle diverse librerie native; l'altro elemento 
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importante del runtime è costituito dalle core library. Ciò che l' architettura non mette in evidenza è il 
ruolo di Java in tutto questo. In un' architettura Andro id non esiste alcuna virtual machine Java e non 
viene eseguito alcun bytecode Java. Il fatto che Andro id non fosse una specializzazione della 
piattaforma Java ME l'avevamo capito nell'Introduzione, per cui perché parliamo di Java? 
Semplicemente perché per sviluppare applicazioni per Andro id si utilizza (principalmente) Java. Ma 
allora perché non si è utilizzata la Java ME? Beh, la piattaforma Java ME purtroppo non ha avuto lo 
stesso successo delle sorelle Java Standard Edition e Java Enterprise Edition, non avendo mantenuto 
la promessa del "Write Once, Run Everywhere". 
NOTA 

Con JME intendiamo la Java Micro Edition le cui specifiche erano state rilasciate da Sun, ora 
acquisita da Oracle. Con MIDP 2.0 intendiamo invece un particolare insieme di librerie che hanno 
caratterizzato le applicazioni sui dispositivi di ormai qualche anno fa di costruzione principalmente 
Nokia. Per intenderci, è l'ambiente utilizzato per la realizzazione dei classici giochini per cellulare 
ormai estinti a favore delle applicazioni su smartphone. 

I dispositivi mobili in grado di eseguire delle MUDlet erano moltissimi e molto diversi tra loro. 
Realizzare delle applicazioni che funzionassero bene e sfruttassero a dovere le caratteristiche di 
ciascun dispositivo si è rivelata cosa impossibile. Un dispositivo può promettere di eseguire 
applicazioni MIDP 2.0 allo stesso modo di un altro, ma può avere dimensioni, risoluzione e modalità 
di input diverse. Alcuni hanno il Bluetooth altri no, alcuni hanno la fotocamera e altri no. Per questo 
motivo si è portati a realizzare applicazioni specifiche per classi di dispositivi come possono essere 
quelli raggruppati sotto il nome di "classe 60" di Symbian. 
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Figura 1.1 Architettura di Android (http://www.gurubee.net/). 



Un altro aspetto molto importante di Java ME è il suo legame con la piattaforma madre Java SE, di 
cui è un sottoinsieme. Attraverso la classificazione in Configuration e Pwfile si è infatti deciso di 
eliminare dalla versione Java SE tutte quelle istruzioni e API non in grado di poter essere eseguite in 
un dispositivo con risorse limitate in termini di CPU e memoria. La Java ME non è quindi stata 
pensata appositamente come piattaforma mobile ma come "l'insieme delle API che funzionano anche 
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su dispositivi mobili". L'OHA e Google hanno quindi deciso che la cosa migliore per la realizzazione 
di una piattaforma mobile fosse quella di creare subito qualcosa di ottimizzato e specifico senza 
ricadere nel classico "reinvent the wheel" per i componenti principali 

Bene, fin qui abbiamo capito che la Java ME non c'è; ma allora Java cosa c'entra? Un obiettivo 
non secondario della nuova piattaforma è quello di rendere relativamente semplice la creazione di 
applicazioni che alla fine sono quelle che ne determinano il successo. Le possibilità erano quelle di 
creare un nuovo linguaggio oppure di utilizzarne uno esistente ereditando una community di 
sviluppatori e soprattutto un insieme maturo di strumenti di sviluppo. La scelta è caduta su Java non 
solo per questi motivi ma anche per l'opportunità di avere a disposizione unbytecode di specifiche 
conosciute (e, per i maligni, anche libero da qualunque royalty per la certificazione TCK) e quindi 
modificabile e ottimizzabile a piacere. 

Un'applicazione Andro id si sviluppa in Java viene compilata in un insieme di risorse e bytecode 
Java. Quest'ultimo viene poi trasformato in bytecode Dalvik attraverso l'applicazione di una serie di 
ottimizzazioni che lo rendono più compatto ed efficiente a runtime. Ecco che da un'applicazione Java 
si ottiene un bytecode non Java che viene eseguito in una virtual machine non Java. 

Come detto non andremo a descrivere tutti i componenti dell'architettura precedente ma possiamo 
comunque osservare che ci sono sostanzialmente tre diverse parti: 

• sistema operativo; 

• librerie; 

• application framework. 

Il primo contiene la parte dell'architettura di competenza dei costruttori, i quali dovranno adattare il 
sistema operativo con il kernel Linux di riferimento e quindi realizzare i diversi driver per l'interazione 
con il particolare hardware. La seconda parte è quella delle librerie e ha un'importantissima 
caratteristica: non sono sviluppate in Java ma perlopiù in C/C++. Ebbene sì, le applicazioni Andro id si 
sviluppano (principalmente) in Java ma la maggior parte del codice che verrà eseguito sarà codice 
nativo in C/C++. Questo per il semplice fatto che molti dei componenti della piattaforma sono 
semplicemente delle interfacce Java di componenti nativi Questa affermazione era vera soprattutto 
nelle prime versioni della piattaforma; dalla versione 2.2 ci si è accorti che comunque la gran parte del 
codice di un'applicazione faceva riferimento alla UI descritta appunto attraverso del bytecode Dalvik. 
Per questo motivo da questa versione è stato introdotto anche un garbage collector intelligente in 
grado di portare diversi benefici nella gestione della memoria. Infine, il framework applicativo è quella 
parte di architettura che contiene tutti componenti che andremo a utilizzare, personalizzare ed 
estendere per la realizzazione delle nostre applicazioni Come vedremo nei prossimi capitoli, una delle 
principali caratteristiche di Andro id è quella di permettere la realizzazione di applicazioni attraverso gli 
stessi strumenti utilizzati per creare la piattaforma stessa. Potremmo creare, per esempio, la nostra 
applicazione di e-mail da utilizzare poi al posto di quella di Gmail installata su quasi tutti i dispositivi, 
oppure realizzare un'applicazione dei contatti che vada a sostitire quella presente. Viceversa le nostre 
applicazioni potranno utilizzare componenti già esistenti Caso tipico è quello di un'applicazione che 
vuole inviare un'immagine a un determinato contatto attraverso una mail. In Android questa 
applicazione non sarà obbligata a sviluppare la parte di gestione dei contatti, la gallery per la scelta 
dell'immagine e neppure il componente per l'invio del messaggio. Attraverso i concetti fondamentali di 
intent e intent filter che vedremo nel Capitolo 3, capiremo come sia possibile scegliere un contatto 
tra quelli disponibili utilizzando l'applicazione dei contatti esistenti, selezionare un' immagine 
utilizzandola gallery presente e quindi inviare l'e-mail usando una delle applicazioni esistenti II 
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linguaggio che andremo a utilizzare sarà comunque Java anche se, da ormai molto tempo, Android 
permette lo sviluppo in modo completamente nativo attraverso un proprio ambiente chiamato NDK 
{Native Development Kit), che non tratteremo in questo testo data la vastità dell'argomento. 

La Dalvik Virtual Machine 

La conoscenza dei dettagli che stanno dietro questa nuova virtual machine è sinceramente superflua 
nella maggior parte dei casi. Una necessità di questo tipo si ha, per esempio, per alcune applicazioni 
native che utilizzano l'NDK e che quindi hanno bisogno di ottimizzazioni a livello di bytecode. In 
questa sede ci interessa quindi solamente dare alcune informazioni su cosa effettivamente renda 
questa VM interessante. Diciamo quindi che si tratta di una VM progettata e realizzata da Dan 
Borstein con il principale obiettivo di essere ottimizzata per dispositivi mobili Essa è per esempio in 
grado di eseguire più processi contemporaneamente attraverso ima gestione ottimale delle risorse 
condivise. Una delle ottimizzazioni più conosciute riguarda il fatto che si tratta di una VM register- 
based, diversamente dalla KVM che è invece stack-based. 

NOTA 

La KVM (la K indica che le dimensioni erano di 70 KB circa) è la principale virtual machine 
utilizzata dai cellulari per l'esecuzione delle ormai famose MIDIet ovvero le applicazioni per MIDP. 

Attraverso un utilizzo intelligente dei registri di sistema permette una maggiore ottimizzazione della 
memoria in dispositivi con bassa capacità. Si tratta inoltre di una VM ideale per l'esecuzione 
contemporanea di più istanze sfruttando la gestione di processi, memoria e thread del sistema 
operativo sottostante. La Dalvik VM non esegue bytecode Java ma un qualcosa che si può ottenere 
da esso e che prende il nome di Dalvik bytecode. Ecco svelato l'arcano. Le applicazioni per Android 
si sviluppano in Java sfruttando i tool di sviluppo classici come Eclipse, NetBeans e ora Android 
Studio per poi trasformare il bytecode Java in Dalvik bytecode. Su un dispositivo Android non girerà 
alcun bytecode Java ma un bytecode le cui specifiche sono descritte dal formato DEX (Dalvik 
EXecutable). Le core library e tutte le API che avremo a disposizione nella realizzazione delle 
applicazioni per Android saranno quindi classi Java. 

I componenti principali di Android 

La caratteristica della DVM di poter eseguire diverse istanze contemporanee in modo ottimizzato 
non è da sottovalutare. Questo perché Android associa a ciascuna applicazione, distribuita all'interno 
di un file di estensione . apk, un singolo task a cui viene data la responsabilità di gestire più activity, 
ossia quelli che sono i componenti più importanti di una qualunque applicazione per questo sistema e 
che rappresentano quella che è una schermata. Possiamo quindi dire che gli elementi fondamentali di 
Android, dal punto di vista dello sviluppatore, sono i seguenti 

• activity; 

• intent e intent filter; 

• broadcast intent receiver; 

• service: 

• content provider. 

Ora li descriviamo brevemente, per poi approfondirli man mano durante la realizzazione della 
nostra applicazione. 
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Activity 

Potremmo definire uh activity come una schermata di un'applicazione di Andro id, ossia un 
qualcosa che visualizza delle informazioni o permette l'inserimento di dati da parte dell'utente 
attraverso la renderizzazione di quelle che chiameremo view. Un'applicazione sarà perlopù costituita 
da più activity ciascuna delle quali verrà eseguita da un proprio processo all'interno di uno o più task. 
Il compito degli sviluppatori sarà quello di creare le diverse activity attraverso la descrizione delle 
view e delle modalità con cui le stesse si passano le informazioni. Di fondamentale importanza è la 
gestione del ciclo di vita delle attività attraverso opportuni metodi di callback. Si tratta di un aspetto 
importante di Andro id a seguito della politica di gestione dei processi delegata perlopù al sistema che, 
in base alla necessità, può decidere di terminarne uno o più. In quel caso si dovranno adottare i giusti 
accorgimenti per non incorrere in perdita di informazioni. Da notare come attraverso il plug-in fornito 
da Google sia possibile definire le view in modo dichiarativo attraverso alcuni file XML di 
configurazione che prendono il nome di layout. 

Intent e intent filter 

Come abbiamo accennato, l'architettura diAndroid è ottimizzata in modo da permettere uno 
sfruttamento migliore delle risorse disponibili. Per raggiungere questo scopo si è pensato di "riciclare" 
quelle attività che svolgono operazioni comuni a più applicazioni Per riprendere l'esempio 
precedente, consideriamo la semplice selezione di un contatto dalla rubrica. Il fatto che ciascuna 
applicazione possa gestire il modo con cui un'azione avviene ha il vantaggio di permettere una 
maggiore personalizzazione delle applicazioni, ma ha il grosso svantaggio di fornire diverse modalità, 
spesso pure simili tra di loro, per eseguire una stessa operazione. Un utente che utilizza un dispositivo 
si aspetta di compiere la stessa operazione sempre nelle stesso modo in modo indipendente 
dall'applicazione. Ecco che si è deciso di adottare il meccanismo degli intent, che potremmo tradurre 
in "intenzioni". Attraverso un intent, un'applicazione può dichiarare la volontà di compiere una 
particolare azione senza pensare a come questa verrà effettivamente eseguita. Nell'esempio 
precedente il corrispondente intent potrebbe essere quello che dice "devo scegliere un contatto dalla 
rubrica". A questo punto serve un meccanismo che permetta di associare tale intent a un' activity per 
la sua esecuzione. Ciascuna activity può dichiarare l'insieme degli intent che la stessa è in grado di 
esaudire attraverso quelli che si chiamano intent filter. Se un' activity ha tra i propri intent filter quello 
relativo alla scelta di un contatto dalla rubrica, quando tale intent viene richiesto essa verrà visualizzata 
per permettere all'utente di effettuare l'operazione voluta. Tale attività sarà la stessa per ogni 
applicazione senza che occorra definirne una propria. Questo utilizzo degli intent riguarda la 
comunicazione tra più activity. 

Broadcast intent receiver 

Ormai gli smartphone e i tablet ci seguono dovunque e sanno tutto di noi Sanno dove andiamo, 
come ci andiamo, e sono in grado di rispondere a sollecitazioni di varia natura attraverso la 
percezione di informazioni attraverso un numero sempre maggiore di sensori. In un ambiente come 
quello Andro id serviva quindi un componente in grado di reagire a determinati eventi e quindi attivare 
un'applicazione, visualizzare una notifica, iniziare a vibrare o altro ancora. Questo tipo di componenti 
vengono descritti dal concetto di broadcast intent receiver, che sono in grado di attivarsi a seguito 
del lancio di un particolare intent che si dice appunto di broadcast. Gli eventi possono essere generati 
dalle applicazioni o direttamente dal dispositivo. Parliamo della ricezione di una telefonata, di un 
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SMS, del segnale di batteria scarica, della disponibilità della rete prima assente e altro ancora. 

Service 

In precedenza abbiamo associato le activity a delle schermate. Nel caso in cui si rendessero 
necessarie delle lùnzionalità long running (di esecuzione prolungata) non direttamente legate ad 
aspetti visuali, la piattaforma ci fornisce quelli che si chiamano service. Parliamo di processi con la 
responsabilità di riprodurre file multimediali, leggere o scrivere informazioni attraverso la rete o 
attraverso le informazioni dell'eventuale GPS integrato. Per il momento possiamo pensare ai service 
come a un insieme di componenti in grado di garantire l'esecuzione di alcuni task in background in 
modo indipendente da ciò che è visualizzato nel display, e quindi con ciò da cui l'utente in quel 
momento sta interagendo. 

Content provider 

Dall'immagine dell'architettura notiamo come Android metta a disposizione un SQLite per la 
gestione della persistenza di informazioni comunque limitate, per default, a ciascuna singola 
applicazione. Se si intende fornire un insieme di dati per più applicazioni, che ricordiamo sono in 
esecuzione in processi diversi, è di fondamentale importanza il concetto di content provider. 
Possiamo pensare a un componente di questo tipo come a un oggetto che offre ai propri client 
un'interfaccia per l'esecuzione delle operazioni di CRUD (Create, Retrieve, Update, Delete) su un 
particolare insieme di entità. Chi ha esperienza in ambito JEE può pensare al content provider come a 
una specie di DA, il quale fornisce un'interfaccia standard ma che può essere implementato in modi 
diversi interagendo con una base dati, su file system, su cloud o semplicemente in memoria. 

Cosa rende Android particolare 

Dopo aver descritto i componenti principali dell' architettura di Android vediamo di descrivere 
alcuni degli aspetti della piattaforma che lo rendono diverso dalle tecnologie o architetture alternative. 

Definizione dichiarativa della Ul 

Attraverso l'utilizzo di opportuni documenti XML, facilmente gestibili con il plug-in messo a 
disposizione da Google, è possibile creare in maniera dichiarativa l'interfaccia grafica delle 
applicazioni Lo stesso plug-in permette di avere, in ogni momento, una preview del risultato 
dell'interfaccia realizzata. L'utilizzo di questo approccio è stato un passo obbligato legato alla 
presenza di innumerevoli versioni dei dispositivi Android. 

Ciascuna applicazione può essere consumere provider di informazioni 

Utilizzando il meccanismo degli intent e dei content provider si può fare in modo che le diverse 
applicazioni collaborino tra loro per la gestione dei contenuti secondo il paradigma Web 2.0. Si tratta 
quindi di un vero e proprio ambiente all'interno del quale più applicazioni possono convivere con un 
utilizzo ragionato delle risorse. A tale proposito possiamo pensare ad Android come una vera e 
propria piattaforma che offre una serie di strumenti utilizzabili in modo relativamente semplice 
all'interno delle nostre applicazioni. Pensiamo alla possibilità di accedere ai servizi di Google Maps 
per la realizzazione di applicazioni location-based, o alla semplicità con cui si può interagire con i 
servizi di telefonia o di gestione degli sms o con lo stesso browser integrato. Lo sviluppatore si 
concentrerà su quelli che sono i servizi di business senza preoccuparsi della creazione di strumenti a 
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supporto, che potremo comunque realizzare avendo a disposizione un intero stack. 

Il codice sorgente è open source 

Android non solo utilizza tecnologie open source ma il suo stesso codice è ora disponibile sotto 
licenza Apache 2.0. 

È basato sulle API della Java SE ma non esegue bytecode Java 

Per quello che riguarda le API Java disponibili, queste sono relative alla piattaforma Java SE (e non 
a quella Java ME) con un numero di sviluppatori sicuramente superiore, che quindi può iniziare a 
sviluppare applicazioni Android con ima curva di apprendimento molto breve. Notiamo come 
l'analogia con la Java SE sia stata fatta a livello diAPI e non di implementazione. L'applicazione in 
esecuzione sul dispositivo Android viene eseguita all'interno di una VM che è strettamente legata alle 
risorse del sistema operativo Linux. Questo significa che l'applicazione pseudo- Java è praticamente 
nativa rispetto al dispositivo con notevoli vantaggi dal punto di vista delle prestazioni In un dispositivo 
Android non viene eseguito bytecode Java e non esiste alcuna VM Java. 

Quelle descritte sono tutte caratteristiche che fanno di Android una piattaforma di grande interesse 
che impareremo a padroneggiare per la realizzazione di applicazioni molto interessanti 

Le applicazioni di Android 

Come detto, il successo di una piattaforma come Android verrà deciso dalle applicazioni 
disponibili A tale proposito la politica di Google è molto chiara e prevede la possibilità di utilizzo di un 
ambiente di sviluppo e di un emulatore per il test delle applicazioni. Attraverso quello che si chiama 
Google Play chiunque, dopo una spesa di 25$, può vendere (o regalare) le proprie applicazioni È 
una politica per certi versi opposta a quella di iPhone, dove per sviluppare le applicazioni è necessario 
registrarsi alla comunità di sviluppatori e utilizzare anche strumenti e canali ben definiti Non ci resta 
quindi che dare sfogo alla nostra fantasia e realizzare non solo i classici giochi ma soprattutto 
applicazioni che sfruttano le potenzialità delle mappe di Google e la possibilità di interagire con le 
funzionalità del telefono. Pensiamo non solo al fatto di poter cercare i ristoranti o altri punti di 
interesse vicini alla nostra attuale posizione, ma anche di determinare il tragitto per arrivarvi o iniziare 
una chiamata per la prenotazione. Sebbene non si tratti certo di un' applicazione originale, con 
Android la novità consiste nella semplicità con cui la stessa può essere realizzata e nel fatto che essa 
potrà veramente essere fruita da tutti i dispositivi abilitati che cominceranno presto a essere prodotti 
da varie aziende. 

Introduzione a Java 

Come abbiamo detto all'inizio, il linguaggio principale con cui si sviluppano le applicazioni Android 
è Java, e per questo motivo abbiamo deciso di dedicare qualche pagina a quegli che sono gli aspetti 
del linguaggio che ci saranno più utili II lettore già a conoscenza del linguaggio potrà tranquillamente 
passare al capitolo successivo, dove inizieremo lo sviluppo dell'applicazione che abbiamo scelto 
come pretesto per lo studio della piattaforma. 

NOTA 

Gli esempi che descriveremo in questa fase verranno messi a disposizione come progetti per 
eclipse, ma possono essere importati in modo semplice anche in altri IDE, compreso Android 
Studio, che vedremo nel capitolo successivo. 
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Iniziamo allora dalla celeberrima applicazione Hello worid, leggermente modificata, di cui 
riportiamo il codice nella sua interezza: 

package uk . co . massimocarli . javacourse . hello; 

import java . util . Date; 
/** 

* La classica applicazione Hello World 
*/ 

public class HelloWorld { 

/* 

* Il messaggio da stampare 
V 

private static final String MESSAGE = "Hello World!"; 

/** 

* Questo è il metodo principale dell'applicazione 

* Sparam args : array con i parametri dell'applicazione 

*/ 

public static void main ( String [ ] args) { 
final Date now = new Date(); 
// Stampa il messaggio Hello World! 
System. out .println (MESSAGE + " " + now); 

} 

} 

Dalla prima istruzione che inizia con la parola chiave package seguita da un identificativo composto 
da tutte parole minuscole divise dal punto. Un package rappresenta quindi un modo per raggruppare 
definizioni che fanno riferimento a cose comuni Per esempio, la piattaforma fornisce il package 
java . net, che raccoglie tutte le classi e gli strumenti relativi al networking, alle operazioni di I/O e così 
via. In Java non possiamo creare definizioni in package che iniziano per java o javax e vedremo che 
una limitazione simile esiste anche per le definizioni dei package che iniziano per android. 

NOTA 

Il lettore avrà notato che non abbiamo ancora parlato di classi ma di definizioni. Questo perché un 
package non contiene solamente la definizione di classi ma anche di interfacce, enum 0 annotation. 
Per semplificare di seguito faremo riferimento alle classi ricordandoci però che lo stesso varrà per 
queste due interfacce. 

Sebbene non si tratti di qualcosa di obbligatorio, è sempre bene che ima classe appartenga a un 
proprio package, il quale definisce delle regole di visibilità che vedremo tra poco. Se non viene 
definita, si dice che la classe appartiene al package didefault. Come possiamo vedere nel nostro 
esempio, il nome del package segue anche una convenzione che prevede che lo stesso inizi per il 
dominio dell'azienda ordinato inversamente. Nel caso in cui avessimo un'azienda il cui dominio è del 
tipo www.miazienda.co.uk, i vari package delle applicazione che la stessa vorrà produrre saranno del 
tipo: 

co . uk . mi azienda . android 

È importante inoltre sottolineare come non esista alcuna relazione gerarchica tra un package di 
nome 

nomel . nome 2 

e il package 

nomel . nome2 . nome3 

in quanto si tratta semplicemente di due package di nomi diversi La gerarchia si avrà invece nelle 
corrispondenti cartelle che si formeranno in fase di compilazione. Ultima cosa riguarda il nome della 
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classe, che nel nostro caso non è semplicemente Heiioworid ma 

uk. co. massimocarii. javacourse. hello. Heiioworid. Il nome diuna classe è sempre comprensivo 
del relativo package; questa regola è molto importante e ci permette di distinguere per esempio la 
classe List del package java.awt per la creazione di interfacce grafiche o l'interfaccia List del 
package java, ut il per la gestione della famosa struttura dati 

Abbiamo quindi detto che ogni classe dovrebbe essere contenuta in un package, che impone anche 
delle regole divisibilità. Ogni classe è infatti visibile automaticamente alle classi del proprio package e 
vede sempre tutte le classi di un package particolare che si chiama j ava . lang. Il package j ava . lang 
è quello che contiene tutte le definizioni più importanti, come la classe object da cui derivano tutte le 
classi Java in modo diretto o indiretto, la classe string, tutti i wrapper (i nteger, Boolean...) e COSÌ 
via. Nel caso in cui avessimo bisogno di utilizzare classi di altri package è possibile utilizzare la parola 
chiave i mport. Nel nostro esempio abbiamo utilizzato l'istruzione 

import java . util . Date; 

per importare in modo esplicito la classe Date del package java.utii. Nel caso in cui avessimo la 
necessità di importare altre classi dello stesso package possiamo semplicemente utilizzare lo stesso 
tipo di istruzione oppure scrivere 

import java.utii.*; 

Anche qui due considerazioni fondamentali. La prima riguarda un fatto già accennato, ovvero che 
l'istruzione precedente non comprende l'import delle classi del package j ava . util . concurrent 
("sottopackage" del precedente), il quale dovrebbe essere esplicitato attraverso questa istruzione: 

import java . util . concurrent .* ; 

La seconda riguarda il fatto che un'operazione di import non è assolutamente un'operazione di 
include, ovvero un qualcosa che carica del codice e lo incorpora all'interno dell'applicazione. Il 
numero di import non va a influire sulla dimensione della nostra applicazione ma descrive un 
meccanismo che permette alla VM di andare a cercare il bytecode da eseguire tra un numero 
predefinito di location. 

Eccoci giunti alla creazione della classe di nome Heiioworid attraverso la seguente definizione: 

public class HelloWorld { 
} 

La prima parola chiave, public, si chiama modificatore di visibilità e permette di dare indicazioni su 
dove la nostra classe può essere utilizzata. Java prevede quattro livelli di visibilità ma tre differenti 
modificatoli i quali possono essere applicati (con alcune limitazioni) a una definizione, ai suoi attributi 
e ai suoi metodi. I livelli di visibilità con i relativi qualificatori sono i seguenti; 

• pubblico (public); 

• friendly o package (nessun modificatore); 

• protetto (protected); 

• privato (private). 

Nel nostro esempio la classe Heiioworid è stata definita pubblica e questo comporta che la stessa 
sia visibile in un qualunque altro punto dell'applicazione. Attenzione: questo non significa che se ne 
possa creare un'istanza ma che è possibile almeno creare un riferimento di tipo Heiioworid: 

HelloWorld hello; 

Di seguito abbiamo utilizzato la parola chiave class, che ci permette appunto di definire una class, 
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che sappiamo essere un modo per descrivere, in termini di attributi e comportamento, un insieme di 
oggetti che si dicono sue istanze. Abbiamo poi il nome della classe, che le convenzioni impongono inizi 
sempre con una maiuscola e quindi seguano la carnei notation, che prevede di mettere in maiuscolo 
anche le iniziali delle eventuali parole successive. 
NOTA 

A proposito del nome della classe esiste un'importante regola spesso trascurata. All'interno di un 
file sorgente di Java vi può essere la definizione di un numero qualunque di classi, interfacce e così 
via. L'importante è che di queste ve ne sia al massimo una pubblica, che dovrà avere lo stesso 
nome del file. Questo significa che all'interno di un file sorgente potremo definire un numero 
qualunque di classi di visibilità package e dare al file un nome qualsiasi. Se però solamente una di 
queste classi fosse pubblica (nel qual caso sarebbe comunque la sola), il file dovrà avere il suo 
stesso nome. 

Il corpo della classe viene poi descritto all'interno di quello che si chiama blocco e che è compreso 
tra le due parentesi grafie { } . Lo vedremo anche in un paragrafo successivo, ma la definizione 
precedente è equivalente alla seguente: 

public class HelloWorld extends Object { 
} 

Ogni classe Java estende sempre un'altra classe che, se non definita in modo esplicito, viene 
impostata dal compilatore. Quella definita è una classe esterna o top leveL Vedremo successivamente 
come si possono definire classi interne e anonime. 

Per le definizioni top level, public è l'unico modificatore che possiamo utilizzare in quanto la 
visibilità alternativa è quella package o friendly, che non utilizza alcun modificatore. In questo caso la 
classe sarebbe stata definita in questo modo: 

class HelloWorld { 
} 

e la visibilità sarebbe stata ristretta solamente alle classi dello stesso package. È importante quindi 
sottolineare come le classi top level non possano assolutamente avere visibilità protected o private. 

Procedendo con la descrizione della nostra applicazione, notiamo la seguente definizione che 
contiene ancora dei modificatori interessanti; 

private statìc final Strìng MESSAGE = "Hello World!"; 

Il primo elemento è il modificatore di visibilità private, il quale permette di limitare al solo file la 
definizione della costante message. 
ATTENZIONE 

Qui abbiamo parlato di file e non di classe. Tale definizione, sebbene privata, sarebbe perfettamente 
visibile all'interno di eventuali classi interne. 

Segue quindi la parola chiave che può essere applicata solamente ad attributi, come in questo caso, 
e a metodi. Nel caso degli attributi il significato è quello di un valore condiviso tra tutte le istanze della 
corrispondente classe. Nel caso specifico, se creassimo un numero qualunque istanze di Heiioworid, 
tutte condividerebbero lo stesso valore di message. L'aspetto interessante è però relativo allatto che 
un attributo statìc esiste anche se non esistono istanze della relativa classe. Si parla di attributi di 
classe in quanto vengono creati nel momento in cui il bytecode viene letto e interpretato dal 
ciassLoader. Proprio per questo motivo possono essere referenziati non attraverso un riferimento a 
un' istanza ma attraverso il nome della classe. Trascurando per un attimo il fatto che si tratti di un 
attributo privato, l'accesso a esso avverrebbe attraverso questa sintassi; 

<Nome Classe> . <attributo static> 
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HelloWorld.MESSAGE 

Il modificatere static applicato ai metodi ha un significato analogo per cui permette la definizione 
di metodi che non dipendono dallo stato delle istanze di una classe e che possono essere invocati 
come nell'esempio precedente. Si tratta principalmente di metodi di utilità che hanno nei propri 
parametri tutte le informazioni che servono per assolvere al proprio compito. Vedremo tra poco cosa 
comporterà questa osservazione con il metodo main ( ) . Una top class non può essere definita come 
static, a differenza di quelle inteme che vedremo più avanti 

Il terzo modificatere è molto importante e si chiama final. Può essere applicato sia alle classi sia 
agli attributi e metodi ma con significati diversi Una classe final è una classe che non può essere 
estesa; il compilatore utilizza questa informazione per applicare tutte le possibili ottimizzazioni in 
quanto è sicuro che alcune funzionalità non verranno modificate attraverso overriding. Nel caso di un 
metodo il significato è quello appunto di impedirne l' overriding, mentre nel caso di un attributo il 
significato è quello di definizione di una costante. Per essere più precisi un attributo final è un 
attributo che può essere valorizzato solamente una volta e prima che venga invocato il costruttore 
della corrispondente classe. 

Quella precedente è quindi la definizione di una costante di nome message, visibile solamente 
all'interno del file Heiioworid. 

Talvolta è facile confondere il concetto di private e di static e ci si chiede come faccia qualcosa 
che viene condiviso tra tutte le istanze di una classe a non essere pubblico. In realtà sono concetti 
indipendenti tra loro. Il primo riguarda il fatto che si tratta di qualcosa che è visibile solamente 
all'interno della classe. Il secondo esprime il fatto che si tratta comunque di qualcosa che è associato 
alla classe e non alle singole istanze. 

Passiamo finalmente a descrivere il metodo che caratterizza un'applicazione Java e che ne permette 
l'esecuzione: 

public static void main (String [ ] args) 

In relazione a quanto detto notiamo che si tratta di un metodo pubblico e statico di nome maìn con 
un parametro di tipo array string. È importante sottolineare come questo debba essere il metodo di 
avvio dell'applicazione; ogni eventuale differenza renderebbe l'applicazione non awiabile. 

Se volessimo eseguire la nostra applicazione da riga di comando utilizzeremmo la prossima 
istruzione, dove notiamo che la classe è specificata in modo comprensivo del relativo package: 

java uk . co . massimocarli . javacourse .hello . HelloWorld 

Il comando java non è altro che l'interprete che caricherà ilbytecode della nostra classe per 
eseguirlo. Ma come fa l'interprete a eseguire del codice che non conosce? C'è la necessità di un 
punto di ingresso standard che ogni applicazione Java ha e che l'interprete si aspetta di chiamare in 
fàse di avvio. Questo è il motivo per cui il metodo deve essere pubblico, deve avere void come tipo 
di ritorno e si deve chiamare maìn con un array string come tipo del parametro di ingresso che 
rappresenta gli eventuali parametri passati Anche qui la parte interessante sta nell' utilizzo della parola 
chiave static. L'interprete caricherà ilbytecode della classe specificata per cui tutti i membri statici 
saranno già definiti. Di seguito invocherà quindi il metodo main senza dover creare alcuna istanza di 

HelloWorld. 

Infine, all'interno del metodo main ( ) , non facciamo altro che inizializzare un'altra variabile final da 
utilizzare poi per la visualizzazione del nostro messaggio. 

È buona norma utilizzare il modificare final il più possibile rimuovendolo solamente nel caso in cui 
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la corrispondente proprietà abbia la necessità di cambiare. Qui è importante tare una considerazione 
relativamente al concetto di costante e di immutabilità. Per intenderci, la seguente istruzione: 

final MiaClasse me = new MiaClasse () ; 
me . setProp (newalue) ; 

è perfettamente valida in quanto non viene cambiato il valore del riferimento me che è stato definito 
come final ma, attraverso il metodo setProp o , ne viene modificato lo stato. Se questo non fosse 
possibile si parlerebbe di immutabilità. 

Concludiamo allora con la seguente istruzione, che nasconde diversi concetti della programmazione 
Java: 

System. out .println (MESSAGE + " " + now) ; 

Da quanto visto, system è una classe che, non essendo stata importata, intuiamo appartenere al 
package java . ìang. È una classe anche perché inizia con una lettera minuscola. Da questo capiamo 
anche che out è una proprietà statica sulla quale possiamo invocare i metodi println ( ) , nel cui 
parametro notiamo una concatenazione di strìng attraverso l'operatore +. In Java non esiste la 
possibilità di ridefinire gli operatori, ma nel caso delle string il + ha il significato di concatenazione. 
Eseguendo l'applicazione si ottiene però un risultato di questo tipo: 

Hello World! Thu Jun 06 23:40:45 BST 2013 

La concatenazione di un oggetto di tipo Date a una string provoca il risultato di cui sopra. In 
realtà quando un riferimento a un oggetto viene concatenato a una stringa si ha l'invocazione del 
metodo tostring ( ) che tutti gli oggetti ereditano dalla classe ob ject. 

Fin qui abbiamo visto le parole chiave principali e come si utilizzano all'interno della nostra azienda. 
I modificatoli non solo di visibilità di Java sono diversi, ma quelli elencati sono sicuramente ipiù 
importanti Avremo comunque occasione di ulteriori approfondimenti durante la realizzazione del 
nostro progetto. 

Concetti object-oriented 

Prima di proseguire con gli strumenti e i pattern più utilizzati in Android facciamo un breve riassunto 
di quelli che sono i concetti di programmazione ad oggetti più importanti, che sappiamo essere: 

• incapsulamento; 

• ereditarietà; 

• polimorfismo. 

Sono tra loro legati e sono stati introdotti con l'unico scopo di diminuire l'impatto delle modifiche 
nel codice di un'applicazione. Sappiamo infatti che il costo di una modifica cresce in modo 
esponenziale man mano che si passa da una fase di analisi alla fase di progettazione e sviluppo. In 
realtà il nemico vero è rappresentato dal concetto di dipendenza. Diciamo che un componente B 
dipende dal componente A se quando A cambia anche B deve subire delle modifiche. Da questa 
definizione capiamo come limitando la dipendenza tra i diversi componenti diminuisce il lavoro da 
fare. Un primo passo verso questo obiettivo è rappresentato dall'incapsulamento, secondo cui lo 
stato di un oggetto e il come lo stesso assolve alle proprie responsabilità debbano rimanere nascosti e 
quindi non visibili agli oggetti con cui lo stesso interagisce. Questo significa che i diversi oggetti 
devono comunicare invocando delle operazioni il cui insieme ne rappresenta l'interfaccia. Per 
comprendere questo concetto vediamo un semplice esempio con la classe Point2D, che contiene le 
coordinate di un punto nello spazio. Una prima implementazione di questa classe potrebbe essere 
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questa: 

public class Point2D { 
public doublé x; 
public doublé y; 

} 

la quale è caratterizzata dall'avere due attributi con visibilità public. Questo significa che è 
possibile utilizzare la classe Point2D come segue: 

Point2D p = new Point2D(); 
p.x = 10.0; 
p . y = 2 0.2; 

In queste poche righe di codice non sembra esserci nulla di male, anche se si potrebbero fare 
moltissime considerazioni dal punto di vista del multithreading. Il nostro punto ha comunque due 
attributi che rappresentano le coordinate x e y. Tutte le classi che utilizzano questo oggetto avranno 
delle istruzioni che usano, attraverso un riferimento di tipo Point2D, tali proprietà. Ma cosa succede 
se, infuturo, il punto del piano non fosse più rappresentato da x e y ma da r e 0, che rappresentano 
rispettivamente il modulo e l'angolo del punto secondo un sistema di riferimento polare? Tutte le classi 
che utilizzano il codice precedente dovrebbero modificare il loro, non solo per il nome delle variabili, 
ma soprattutto dovrebbero provvedere alla conversione tra i due sistemi In questo caso un buon 
incapsulamento ci avrebbe aiutato in quanto ci avrebbe permesso inizialmente di creare questa classe: 

public class Point2D { 
private doublé x; 
private doublé y; 

public EncapsulatedPoint2D (doublé x, doublé y) { 
this.x = x; 
this.y = y; 

} 

public doublé getx ( ) { 
return x; 

} 

public doublé getY ( ) { 
return y; 

} 

public void setx (doublé x) { 
this.x = x; 

} 

public void setY (doublé y) { 
this.y = y; 

} 

} 

In questo caso gli utenti interagiscono con il nostro punto utilizzando i metodi getxxx ( ) e setxxx ( ) . 
Ma cosa succederebbe nel caso di modifica della modalità di memorizzazione dei dati da cartesiana a 
polare come nel caso precedente? In questo caso sarà sufficiente modificare la classe nel seguente 
modo: 

public class Point2D { 
private doublé r; 
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private doublé theta; 



public Point2D (doublé x, doublé y) { 
this.r = Math . sqrt (x*x + y*y) ; 
this. theta = Math . atan2 (y , x) ; 

} 

public doublé getx ( ) { 

return r * Math . cos (theta) ; 

} 

public doublé getY ( ) { 

return r * Math . sin (theta) ; 

} 

public void setx (doublé x) { 
final doublé y = getY ( ) ; 
this.r = Math . sqrt (x*x + y*y) ; 
this. theta = Math . atan2 (y , x) ; 

} 

public void setY (doublé y) { 
final doublé x= getx ( ) ; 
this.r = Math . sqrt (x*x + y*y) ; 
this. theta = Math . atan2 (y , x) ; 

} 

} 

Indipendentemente dalla complessità dell'implementazione, gli utilizzatori non si accorgerebbero 
della differenza in quanto la loro modalità di interazione sarà sempre del tipo: 

Point2D p = new Point2D (10 . 0, 20.5); 
doublé x = p.getXO; 
doublé y = p.getYO; 

ovvero attraverso la sua interfaccia, che come possiamo vedere non è cambiata. La lezione in tutto 
questo è comunque quella di nascondere il più possibile come un oggetto esegue le proprie operazioni 
in modo che gli eventuali utilizzatori non dipendano da esso. L'esempio appena descritto utilizza un 
particolare tipo di classe che spesso viene chiamata, in ambienti magari non mobile, entità. Si tratta 
infatti di una classe che non descrive operazioni ma che permette la semplice memorizzazione di 
informazioni In ambiente Android non è raro trovare delle classi descritte come nel primo caso, 
ovvero attraverso un solo elenco di attributi pubblici senza l'utilizzo di un lungo elenco di metodi get 
(accessor) e set (mutator). Un caso in cui questo può avvenire è per esempio quello di classi inteme 
la cui visibilità è garantita dalla classe esterna oppure classi a cui si accede da più thread. La regola 
generale prevede quindi di non scrivere del codice che già in partenza sappiamo essere inutile. 

Diverso è il concetto di incapsulamento applicato a classi che hanno responsabilità che possiamo 
chiamare di servizio. Anche qui facciamo un esempio relativo a una semplice classe che dispone di un 
metodo che permette la moltiplicazione di due interi Una prima implementazione potrebbe essere 
questa: 

public class Calculator { 

public int multiply ( final ìnt a, final int b) { 
int res = 0; 

for (int i=0; i< a; i++) { 
res += b; 

} 

return res; 

} 

} 

la quale prevede appunto un metodo multiply ( ) che moltiplica due valori interi sommando il 



secondo tante volte quanto indicato dal primo. Supponiamo di utilizzare questa versione per poi 
accorgerci che in alcuni casi non funziona. Pensiamo per esempio al caso in cui i parametri fossero 
negativi. Decidiamo allora di modificare la classe nel seguente modo: 

public class Calculator { 

public int multiply ( final ìnt a, final ìnt b) { 
return a * b; 

} 

} 

In questo caso chi utilizzava il metodo muitipiy o sull'oggetto calculator prima potrà continuare 
a farlo anche dopo senza accorgersi della modifica. Quello descritto è in realtà qualcosa di più del 
concetto di incapsulamento, in quanto ci permette di definire una struttura che in Java è di 
fondamentale importanza, ovvero l'interfaccia. Se osserviamo la classe precedente notiamo come ciò 
che interessa al potenziale utilizzatore è cosa un oggetto fa e non come questo avviene. Cosa un 
oggetto è in grado di fare può essere descritto attraverso un'interfaccia definita nel seguente modo: 

public interface Calculator { 

int multiply (int a, int b) ; 

} 

Si tratta quindi di un modo per elencare una serie di operazioni che un insieme di oggetti è in grado 
di assicurare. Quando una classe prevede tra le sue operazioni quelle descritte da un'interfaccia, si 
dice che "implementa" questa interfaccia. L'implementazione precedente può quindi essere definita nel 
seguente modo: 

public class MyCalculator implements Calculator { 

public int multiply ( final int a, final int b) { 
return a * b; 

} 

} 

Ma qual è il vantaggio che si ha nel definire un'interfaccia e quindi un insieme di possibili 
implementazioni? Si tratta del concetto forse più importante della programmazione ad oggetti; il 
polimorfismo. Ogni oggetto interessato a utilizzare un calculator avrebbe potuto scrivere al proprio 
interno del codice di questo tipo: 

MyCalculator cale = new MyCalculator () ; 
int res = cale .multiply (10, 20) ; 

Il vantaggio nell'utilizzo dell'interfaccia sarebbe stato nullo inquanto quello che possiamo chiamare 
client (inteso come colui che utilizza), sa esattamente chi è l'oggetto a cui andrà a chiedere il servizio. 
Abbiamo visto in precedenza che il nostro nemico è la dipendenza, che è tanto inferiore quanto meno 
i diversi oggetti conoscono imo dell'altro in relazione alla propria implementazione. Al nostro client 
interessa solamente effettuare una moltiplicazione e quindi ha bisogno di un oggetto in grado di poterla 
effettuare. L'insieme di tutti questi oggetti può essere espresso attraverso un riferimento di tipo 
calculator e quindi il codice precedente può diventare: 

Calculator cale = new MyCalculator () ; 
ìnt res = cale .multiply (10, 20) ; 

In questo caso il client conosce però chi è il componente che eseguirà la moltiplicazione, per cui il 
miglioramento non è poi così grande. Si può fare di meglio con del codice del tipo: 

private Calculator mCalculator; 
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public void setCalculator ( final Calculator oalculator) { 
this .mCalculator = calculator; 

} 

ìnt res = mCalculator . multiply ( 10 , 20 ) ; 

dove il nostro client non sa chi è il particolare calculator ma confida nel latto che qualcuno 
dall'esterno gli passi un suo riferimento attraverso l'invocazione del metodo setcaicuiator ( ) . 
L'aspetto importante qui si può riassumere nella possibilità di eseguire un'assegnazione del tipo: 

Calculator calculator = new MyCalculator ( ) ; 

Attraverso un riferimento di tipo calculator possiamo referenziare una qualsiasi implementazione 
dell'omonima interfaccia qualunque essa sia. Il tipo del riferimento ci dice che cosa si può fare, mentre 
l'oggetto referenziato ci dice come questo viene implementato. Il fatto che il client utilizzi un 
riferimento di tipo calculator esprime questo disinteresse verso il chi ma l'interesse verso il cosa. 

Ma in Andro id dove viene utilizzato il polimorfismo? Adire il vero la piattaforma non utilizza questa 
importantissima caratteristica nel modo appena descritto, anche se il concetto di interfaccia e relativa 
implementazione rimane fondamentale. Vedremo, per esempio, cosa succede nella creazione dei 
service. Si tratta di qualcosa che sarà bene utilizzare nel codice delle nostre applicazioni come faremo 
in questo libro,. 

Il concetto forse più importante in Andro id è quello che nello sviluppo enterprise è visto come un 
nemico, ovvero l'ereditarietà. Quella che spesso si chiama implementation inheritance (a differenza 
di quella vista per le interfacce di interface inheritance) rappresenta infatti il vincolo più forte di 
dipendenza. Come vedremo in questo libro, la realizzazione di un' app Reazione Android prevede la 
creazione di alcuni componenti come specializzazione di classi esistenti come activity e service. 
Questo si rende necessario per permettere all'ambiente di gestirne il ciclo di vita attraverso opportuni 
metodi di callback. A mio parere questo rappresenta un problema che poteva essere affrontato in 
modo diverso attraverso la definizione di un delegate, come avviene in altri sistemi come per esempio 
iOS. Una delle regole principali della programmazione ad oggetti dice infatti "Composition over 
(implementation) inheritance", ovvero è meglio utilizzare piuttosto che estendere. È come se la nostra 
classe cnent precedente avesse dovuto estendere la classe Mycaicuiator invece che utilizzarlo 
attraverso un riferimento di tipo calculator come fatto nell'esempio. 

L'ereditarietà in Java presenta inoltre un problema relativo al fatto che è singola. Ogni classe in 
Java può estendere al più un'unica classe (e lo fa sempre almeno conia classe object) e 
implementare un numero teoricamente illimitato di interfacce. In Android esistono diverse librerie che 
hanno l'esigenza di "attaccarsi" al ciclo di vita dei componenti e in particolare delle activity. Questo 
porta a dover estendere spesso classi del framework. Andando sul concreto, supponiamo di voler 
utilizzare la Compatibility Library, una libreria messa a disposizione da Google per poter usare i 
fragment anche in versioni precedenti la 3.0, nella quale sono stati ufficialmente introdotti 

NOTA 

I fragment verranno affrontati nel Capitolo 4 e ci permetteranno una più granulare organizzazione dei 
layout in modo da semplificarne l'utilizzo in display di dimensione diverse, come per esempio 
smartphone e tablet. 

Per utilizzare i fragment le nostre activity dovranno estendere una classe che si chiama 
FragmentActivity. Ma cosa succede nel caso in cui la nostra classe estendesse già un'altra classe? 
Questo sarebbe comunque un problema facilmente risolvibile in quanto basterebbe risalire nelle nostra 
gerarchia fino alla classe che estende activity sostituendola poi con FragmentActivity. Il problema 
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si ha qualora si decidesse di utilizzare ActionBarSheriook, una libreria che permette di utilizzare 
l'ActionBar anche in versioni della piattaforma precedenti la 3.0. Anche questo framework prevede la 
necessità di estendere una specializzazione della classe Activity. Se poi decidessimo di utilizzare 
anche un framework che si chiama Roboguice? Diciamo quindi che questa decisione di basare tutto 
sull'ereditarietà porta a qualche complicazione che dovremo affrontare di volta involta. 

Il delegation model 

Un concetto strettamente legato a quello di polimorfismo descritto nel paragrafi) precedente è 
quello di delegation model, che sta alla base della gestione degli eventi in Java e quindi anche in 
Android, con qualche modifica per quelle che sono le convenzioni. Innanzitutto cerchiamo di 
descrivere il problema, che è quello di un evento generato da una sorgente e da un insieme di oggetti 
che ne sono interessati e che quindi ne ricevono in qualche modo la notifica. Serve un meccanismo 
affinché la sorgente dell'evento non sappia a priori chi sono quelli che chiameremo listener, i quali 
potrebbero essere istanze di classi qualunque. Da qui capiamo come il concetto alla base di tutto sia 
quello di interfaccia. Facciamo un esempio concreto che prende come riferimento un evento che 
chiamiamo Tic. Se seguissimo le convenzioni descritte dalle specifiche JavaBeans che di fatto hanno 
dato origine a questo meccanismo in Java, il primo passo consisterebbe nella creazione di una classe 
di nome TicEvent in grado di incapsulare tutte le informazioni dell'evento. Nel caso standard questa 
classe dovrebbe estendere una classe di nome tventobject, che descrive la caratteristica che tutti gli 
eventi devono per fòrza avere, ovvero una sorgente che li ha generati. In Android questo non avviene 
e la sorgente dell'evento viene spesso passato come secondo parametro nei metodi di notifica. In 
ogni caso la sorgente è responsabile della memorizzazione dei listener e quindi della notifica 
dell'evento. I listener, come detto, dovranno essere visti dalla sorgente come tutti dello stesso tipo da 
cui la necessità della creazione di un'interfàccia che in Android sarà del tipo: 

public interface OnTicListener { 

void onTick (View src, TicEvent event) ; 

} 

Tutti gli oggetti interessati all'evento dovranno quindi implementare questa interfaccia e il proprio 
metodo onTick o, all'interno del quale forniranno la loro elaborazione delle informazioni ricevute. 
Serve ora un meccanismo per informare la sorgente dell'interesse verso l'evento. Le specifiche 
JavaBeans prevedono la definizione di metodi del tipo: 

public void addTickListener (TicListener listener) ; 
public void removeTickListener (TicListener listener); 

che nel caso Android, ma anche mobile in genere, diventano semplicemente: 

public setOnTickListener (OnTickListener listener) ; 

Aparte la diversa convenzione del prefisso on sul nome dell'interfaccia, notiamo come il prefisso 
add del metodo sia stato sostituito dal prefisso set. Questo sta a indicare che le sorgenti degli eventi 
sono in grado di gestire un unico listener. 

NOTA 

In ambito desktop la possibilità di gestire un numero qualunque di listener ha portato a diversi 
problemi di performance oltre che provocare spesso dei deadlock. 

Il metodo remove è stato eliminato; sarà quindi sufficiente impostare il valore nuli come listener 
attraverso il precedente metodo set. 

Durante lo sviluppo della nostra applicazione avremo modo di vedere quali eventi gestire e come. 
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Per lare questo dobbiamo comunque studiare un altro importante concetto, che è quello delle classi 
inteme, come vedremo nel prossimo paragrafo. 

Le classi interne 

Le classi inteme rappresentano una feature molto interessante che è stata introdotta solamente a 
partire dalla versione 1.1 del JDK. Nella scrittura del codice ci si era infatti resi conto della mancanza 
di uno strumento che permettesse la creazione di determinate classi con visibilità limitata a quella di 
una classe iniziale, che condividesse con essa alcuni dati o che semplicemente fosse legata alla prima 
da un insieme di considerazioni logiche. Ci si è accorti che sarebbe stato molto utile poter definire una 
classe all'interno di un' altra in modo da condividerne tutte le proprietà senza dover creare classi con 
costruttori o altri metodi con moltissimi parametri Più di una feature del linguaggio, quella delle classi 
inteme è quindi relativa al compilatore. A tale proposito possiamo pensare a quattro diversi tipi di 
classi inteme ovvero: 

• classi e interfacce top level; 

• classi membro; 

• classi locali; 

• classi anonime. 

Vediamo di descriverle brevemente con qualche esempio. 

Classi e interfacce top level 

Questa categoria di classi inteme descrive dei tipi che non hanno caratteristiche differenti dalle 
classi che le contengono se non per il fatto di essere legate a esse da una relazione logica di 
convenienza come può essere, per esempio, quella di appartenere a uno stesso package o di 
riguardare uno stesso aspetto della programmazione (I/O, networking e così via). Queste classi 
inteme sono anche dette statiche, in quanto ci si riferisce a esse utilizzando il nome della classe che le 
contiene allo stesso modo di una proprietà statica e della relativa classe. A tale proposito ci 
colleghiamo a quanto detto in relazione alla gestione degli eventi e definiamo la seguente classe: 

public class EventSource { 

public static class MyEvent { 

private final EventSource mSrc; 
private final long mWhen; 

private MyEvent ( final EventSource src, final long when) { 
this.mSrc = src; 
this.mWhen = when; 

} 

public EventSource getSrct) { 
return mSrc; 

} 

public long getWhen ( ) { 
return mWhen; 

} 

} 

public interface EventListener { 
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void eventTriggered (MyEvent event) ; 

} 

private EventListener mListener; 

public void setEventListener ( final EventListener listener) { 
this .mListener = listener; 

} 

private void notif yEvent ( ) { 
if (mListener != nuli) { 

MyEvent event = new MyEvent (this, System . currentTimeMillis ()) ; 
mListener . eventTriggered (event ) ; 

} 

} 

} 

La nostra classe si chiama quindi Eventsource e rappresenta la sorgente di un evento che abbiamo 
descritto attraverso una classe interna statica MyEvent. Notiamo innanzitutto come si tratta di una 
classe statica, che quindi non potrebbe accedere a membri non statici della classe esterna. Se 
provassimo a utilizzare, per esempio, la variabile mListener, noteremmo un errore di compilazione. 
Da notare come la classe MyEvent disponga di un costruttore privato che è comunque accessibile 
dalla classe esterna in quanto all'interno dello stesso file, come detto all'inizio di questo capitolo in 
relazione ai modificatori di visibilità. Questo ci permette di limitare la creazione di istanze di MyEvent 
all'unica sua sorgente, come giusto anche dal punto divista logico. 

Attraverso la definizione dell'interfaccia interna EventListener abbiamo quindi definito l'interfaccia 
che l'eventuale listener dell'evento dovrà implementare. Infine abbiamo creato il metodo per la 
registrazione del listener e imo privato che la sorgente utilizzerà per la notifica dell'evento all'eventuale 
listener. In questa fase è importante notare come le classi in gioco siamo, relativamente al package in 
cui abbiamo definito la classe esterna, le seguenti: 

EventSource 
EventSource . MyEvent 
EventSource . EventListener 

Il nome completo di questo tipo di classi inteme comprende anche il nome della classe esterna. La 
creazione di un' istanza di una di queste classi dall'esterno dovrà contenere tale nome del tipo: 

EventSource . MyEvent myEvent = new EventSource . MyEvent () ; 

sempre nel caso in cui la stessa fosse comunque visibile (cosa che nel nostro esempio precedente 
non avviene). Quindi la regola generale è 

ExtClass . IntClass a = new ExtClass . IntClass ( ) ; 

Questo significa anche che un eventuale listener dovrà essere del tipo: 

public class MyListener implements EventSource . EventListener { 
public void eventTriggered (MyEvent event) { 

} 

} 

e non semplicemente 

public class MyListener implements EventListener { 

public void eventTriggered (MyEvent event) { 

} 

} 

Questo a meno di non utilizzare una delle nuove feature di Java 5 che prevede la possibilità di 
importare i membri statici delle classi attraverso un nuovo tipo di import, che comunque consiglio di 
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trascurare a favore della leggibilità del codice. 

Prima di passare a un altro tipo di classe interna facciamo una piccola ma importante osservazione. 
Mentre la definizione dell'interfaccia è la seguente: 

public interface EventListener { 

void eventTriggered (MyEvent event) ; 

} 

le implementazioni sono del tipo: 

public class MyListener implements EventSource. EventListener { 

public void eventTriggered (MyEvent event) { 

} 

} 

ovvero vi è il modificatere divisibilità public. In realtà nell'interfaccia questo modificatore è 
implicito. Non avrebbe infatti senso definire un'operazione di un'interfaccia come non pubblica. La 
classe quindi non potrebbe essere definita come 

public class MyListener implements EventSource. EventListener { 

void eventTriggered (MyEvent event) { 

} 

} 

in quanto si intenderebbe una visibilità di default o package che rappresenterebbe in questo caso 
una diminuzione di visibilità, cosa che non è possibile. 

Classi membro 

Le classi viste nel paragrafo precedente permettono di creare un legame logico del tipo 
contenitore/contenuto o sorgente evento/evento e così via. La seconda tipologia di classi interne che 
ci accingiamo a studiare è quella delle classi membro, che sono di fondamentale importanza 
specialmente in ambiente Andro id, dove vengono utilizzate moltissimo. In generale una classe membro 
è una classe che viene definita sempre all'interno di una classe esterna. Questa volta però le istanze 
della classe interna sono legate a particolari istanze della classe esterna. Anche qui ci aiutiamo con un 
esempio: 

public class UserData { 

private String mName; 

public UserData ( final String name) { 
this. mName = name; 

} 

public class Printer { 

public void printName ( ) { 

System. out . println ( "The use is : " + mName); 

} 

} 

} 

La classe esterna si chiama UserData e prevede la definizione di improprio attributo che ne 
descrive il nome. Abbiamo poi definito una classe membro interna, che abbiamo chiamato Printer, 
che stampa il valore dell'attributo mName della classe esterna. Come il lettore potrà verificare il codice 
compila facilmente. La domanda che ci poniamo riguarda il come si possa associare un'istanza di 
printer a una precisa istanza di UserData. La soluzione è nel metodo main che abbiamo aggiunto: 
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public static void main (String [ ] args) { 

UserData pippo = new UserData("pippo") ; 
UserData . Printer pi = pippo. new Printer (); 

UserData pluto = new UserData ( "pluto" ) ; 
UserData . Printer p2 = pluto. new Printer (); 

} 

La sintassi da utilizzare è quindi la seguente: 

<istanza classe esterna>.new Classelnterna ( ) ; 

A dire il vero in Andro id non utilizzeremo quasi mai questa sintassi in quanto creeremo le istanze 
delle classi interne direttamente all'interno della classe esterna. Un tipico esempio che vedremo nel 
dettaglio nel Capitolo 3 è questo: 

public class SplashActivity extends Activity { 



private MyHandler mHandler; 
private class MyHandler extends Handler { 
QOverride 

public void handleMessage (Message msg) { 
// Fai qualcosa 

} 

}; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentVìew (R. layout . activity_splash) ; 
mHandler = new MyHandler ( ) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 

mStartTime = SystemClock . uptimeMillis ( ) ; 

final Message goAheadMessage = mHandler. obtainMessage (GO_AHEAD_WHAT) ; 
mHandler. sendMessageAtTime (goAheadMessage, mStartTime + MAX_WAIT_INTERVAL) ; 

} 

} 

dove creeremo una classe interna di nome MyHandler che poi istanzieremo e utilizzeremo 
direttamente dall'interno della nostra classe. La creazione delle istanze dei componenti della 
piattaforma è infatti responsabilità della piattaforma. 

Classi locali 

Proseguiamo la descrizione delle classi interne con quelle che si chiamano locali e che, 
analogamente a come avviene per le variabili, si dicono tali perché definite all'interno di un blocco. 
Sono classiche si possono definire e utilizzare all'interno di un metodo e quindi possono accedere alle 
relative variabili o parametri. Anche in questo caso facciamo un esempio riprendendo le classi statiche 
precedenti: 

public class LocalClassTest { 

private EventSource mSourcel; 
private EventSource mSource2; 
public LocalClassTest ( ) { 
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mSourcel = new EventSource ( ) ; 
mSource2 = new EventSource () ; 

} 

public void useStaticClass ( ) { 
final int num = 0; 

class Locai implements EventSource . EventListener ( 
@Override 

public void eventTriggered (MyEvent event) { 
// Gestione evento 

System. out .println ( "Event with num " + num) ; 

} 

} 

mSourcel . setEventListener (new Locai ( ) ) ; 
mSource2 . setEventListener (new Locai ( ) ) ; 

} 

} 

Abbiamo creato una classe che definisce due attributi di tipo EventSource, che ricordiamo essere 
sorgenti di un evento. La parte interessante è invece all'interno del metodo usestaticciass ( ) , nel 
quale definiamo una classe locale che abbiamo chiamato Locai che poi istanziamo successivamente 
per registrare due listener. È di fondamentale importanza notare come la classe Locai utilizzi al suo 
interno il valore di una variabile locale che abbiamo chiamato num, la quale deve essere 
necessariamente definita come final, il che la rende di fatto costante. Questo è un requisito 
fondamentale nel caso delle classi locali Per capire il perché consideriamo il seguente metodo: 

public EventSource . EventListener externalise ( ) { 
final int num = 0; 
// Definiamo una classe locale 

class Locai implements EventSource . EventListener { 
SOverride 

public void eventTriggered (MyEvent event) { 
// Gestione evento 

System. out . println ( "Event with num " + num) ; 

} 

} 

return new Locai () ; 

} 

Esso ritorna un oggetto di tipo EventSource. EventListener, che nelnostro caso è l'istanza della 
classe locale Locai creata all'interno del metodo e che quindi utilizza il riferimento a num. Essendo una 
variabile locale ci si aspetta che la stessa viva quanto l'esecuzione del metodo. Nelnostro caso, se 
non ne fosse creata una copia, avrebbe vita molto più lunga legata di fatto alla vita dell'istanza 
ritornata. Lo stesso non è vero nel caso in cui num fosse una variabile di istanza. 

Classi anonime 

Eccoci finalmente al tipo di classi interne più utili, ovvero a quelle anonime. Per spiegare di cosa si 
tratta torniamo alla nostra EventSource e supponiamo di voler registrare un listener. In base a quello 
che conosciamo adesso dovremmo scrivere questo codice: 

EventSource source = new EventSource () ; 

class MyListener implements EventSource . EventListener { 
SOverride 

public void eventTriggered (MyEvent event) { 

System . out .println ( "Event with num " + num) ; 

} 

} 
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source . setEventListener (new MyListener ( ) ) ; 

A questo punto ci domandiamo se valga la pena definire una classe, e quindi una sua istanza, 
quando quello che a noi interessa è l'esecuzione del metodo eventTriggeredo a seguito di un 
evento. È in situazioni come questa che ci vengono in aiuto le classi anonime, che ci permettono di 
scrivere il seguente codice equivalente: 

EventSource source = new EventSource () ; 
source . setEventListener (new MyListener () { 
QOverride 

public void eventTriggered (MyEvent event) { 

System. out .println ( "Event with num " + num); 

} 

}); 

Notiamo come si possa creare "on the fly" un'istanza di una classe che implementa una particolare 
interfaccia semplicemente utilizzando la sintassi 

new Interfaccia () { 

// Implementazione operazioni interfaccia 

}; 

Si parla di classe anonima in quanto la classe in realtà non viene definita e quindi non ha un nome. 
Una sintassi analoga si può utilizzare con le classi, ovvero 

new MyClass ( ) { 

// Override dei metodi della classe 

}; 

dove questa volta il significato è quello di creare un'istanza di un'ipotetica classe che estende 
Myciass e di cui si può fare l'override di alcuni metodi Durante la realizzazione del nostro progetto 
vedremo spesso questo tipo di classi non solo nella gestione degli eventi. 

Generics 

L'ultimo argomento che ci accingiamo a trattare è quello dei generics, che sono stati introdotti dalla 
versione 5 della piattaforma Java e ci permettono di creare delle classi parametrizzate rispetto ai tipi 
che le stesse gestiscono. Anche qui ci aiutiamo con qualche esempio che utilizza quelle che si 
chiamano collection e che rappresentano alcune delle strutture dati più importanti in Java. Una di 
queste è per esempio la List, descritta dall'omonima interfaccia del package j ava . util. Essa 
descrive in sintesi una struttura dati che contiene oggetti in modo sequenziale che può essere 
implementata in modi diversi Pensiamo per esempio a un'implementazione che utilizza un array 
descritto dalla classe ArrayList 0 quella che prevede l'utilizzo di una lista concatenata descritta dalla 
classe lì nkedList. In ogni caso, in una lista possiamo aggiungere elementi e quindi accedere agli 
stessi attraverso il concetto di indice. Supponiamo di scrivere le seguenti righe di codice: 

List list = new LìnkedList ( ) ; 
lìst.add(l) ; 
list.add(2) ; 
list.add(3) ; 

le quali permettono la creazione di una lista implementata come lista concatenata, a cui aggiungiamo 
tre oggetti Quest'ultima affermazione potrebbe trarre in inganno se non si conoscesse un'altra 
importante feature di Java 5 che prende il nome di autoboxing. Essa prevede che gli oggetti di tipo 
primitivo vengano automaticamente convertiti in istanze dei corrispondenti tipi wrapper. Nel nostro 
caso gli oggetti inseriti nella lista sono in effetti oggetti di tipo integer. 

La nostra lista può però contenere istanze di ob ject, per cui se aggiungessimo questa istruzione 
non ci sarebbe alcun errore di compilazione né di esecuzione: 
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list.add("four") ; 

Supponiamo ora di voler estrarre i precedenti valori con il seguente codice: 

for (int i = 0; i< list . size ( ) ; i++) { 

Integer item = (Integer) list . get (i) ; 

System. out .println ( "Item :" + itera); 

} 

Sapendo che gli elementi nella lista sono di tipo Integer non facciamo altro che estrarli, farne il 
cast e quindi stamparli a video. 
NOTA 

In realtà il cast sarebbe inutile in quanto nella stampa concateniamo il valore estratto dalla lista con 
la stringa che si ottiene dall'invocazione del metodo astringo. Grazie al polimorfismo il risultato 
sarebbe esattamente lo stesso. 

Se però andiamo a eseguire il nostro ciclo for, che comunque compila con successo, otterremmo 
la seguente eccezione dovuta al fatto che il quarto elemento inserito non è un integer ma una stringi 

Exoeption in thread "main" java . lang . ClassCastException : java . lang . String cannot be cast 
to java . lang . Integer at 

uk . co . massimocarli . javacourse . oo . generics . Generi cTest . main (GenericTest . java : 23 ) 

Abbiamo quindi ottenuto, in fase di esecuzione dell'applicazione, un errore che il compilatore non 
ci aveva messo in evidenza. E in questo contesto che i generics ci vengono in aiuto dandoci la 
possibilità di creare non una semplice List ma un qualcosa di più ovvero una List di integer che 
possiamo esprimere nel seguente modo: 

List<Integer> list = new LinkedList<Integer> ( ) ; 
list.add(l) ; 
list.add(2) ; 
list.add(3) ; 

In questo caso un'istruzione del tipo 

list.add("four") ; 

porterebbe a un errore in compilazione in quanto non si può inserire una string in una lista di 
integer. I vantaggi non si hanno poi solamente nell'inserimento ma soprattutto nell'estrazione dei 
valori Da una List di integer possiamo infatti estrarre solamente integer, per cui non ci sarà 
bisogno di alcuna operazione di cast; di conseguenza, un'istruzione come la prossima è perfettamente 
legale: 

Integer a = list . get (2 ) ; 

I generics sono comunque molto di più. Supponiamo infatti di avere due liste: una di integer e una 
di string, come nel seguente codice: 

List<Integer> list = new LinkedList<Integer> ( ) ; 
list.add(l) ; 
list.add(2) ; 
list.add(3) ; 

List<String> lìst2 = new LinkedList<String> ( ) ; 
list2.add("one") ; 
list2 .addC'two") ; 
list2 .addC'three") ; 

Pensiamo a un metodo che ne permetta la stampa a video. Il primo tentativo del programmatore 
inesperto sarebbe questo: 

public static void print (List<Integer> list) { 
for (Integer item: list) { 

System. out .println (item) ; 

} 

} 
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public static void print (List<String> list) { 
for (String itera: list) { 

System, out .println (itera) ; 

} 

} 

ovvero la realizzazione di due metodi print ( ) che si differenziamo per il tipo di parametro, 
ciascuno associato a una lista di elementi diversa. Questo primo tentativo fallisce inesorabilmente per 
il semplice fatto che per il compilatore i due metodi sono esattamente uguali. Come altre feature, 
anche quella dei generics è legata al compilatore, che comunque crea una List di oggetti in entrambi i 
casi. Il workaround più comunque sarebbe quello di cambiare il nome dei metodi e quindi utilizzarli 
nel seguente modo: 

public class GenericTest2 { 

public static void main ( String [ ] args) { 

List<Integer> list = new LinkedList<Integer> ( ) ; 
list.add(l) ; 
list.add(2) ; 
list.add(3) ; 
printlnteger (list) ; 

List<String> list2 = new LinkedList<String> ( ) ; 
list2 .addC'one") ; 
list2 .addC'two") ; 
list2 .addC'three") ; 
printString(list2) ; 

} 

public static void printlnteger (List<Integer> list) { 

for (Integer itera: list) { 

System. out .println (item) ; 

} 

} 

public static void printString(List<String> list) { 

for (String item: list) { 

System. out .println ( item) ; 

} 

} 

} 

In questo caso il codice compilerebbe e verrebbe eseguito in modo corretto ma sicuramente non 
farebbe fare ima bella figura a Java. Per ogni tipo diverso di List si dovrebbe creare un metodo di 
nome differente che fa esattamente la stessa cosa degli altri. 

NOTA 

A tale proposito approfittiamo per far notare l'utilizzo di quello che si chiama enhanced for che 
permette di scorrere gli elementi di una collection o di un array senza l'utilizzo di un indice. 

In realtà la soluzione esiste ed è rappresentata dal seguente metodo: 

public static void print (List<?> list) { 
for (Object item: list) { 

System. out .println (item) ; 

} 

} 

il quale utilizza una notazione all'apparenza strana che ci permette di definire quella che è una List 
di unknown. Attraverso un riferimento di tipo List<?> possiamo quindi referenziare una lista di un 
tipo qualsiasi ma a un prezzo: da essa possiamo estrarre oggetti ma non inserirne. Vediamo di capirne 
il motivo prendendo un esempio molto classico che utilizza le classi Animai e Dog, dove la seconda 
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descrive una specializzazione della prima. In sintesi, un cane è un animale e quindi un Dog is an 
Animai. Questa affermazione ci permette anche di scrivere questa istruzione: 

Animai a = new Dog(); 

Attraverso un riferimento di tipo Animai possiamo referenziare un Dog. Attraverso questo 
riferimento potremo vedere solamente quelle caratteristiche di un Dog che lo identificano come 
animale. Per essere precisi potremo scrivere 

a . eat ( ) ; 

perché ogni animale è in grado di mangiare (eat) e quindi anche il cane ma non potremo scrivere 

a . bark ( ) 

in quanto sebbene un cane sia in grado di abbaiare (bark) e l'oggetto referenziato da a sia 
effettivamente un cane, noi lo stiamo osservando attraverso un riferimento di tipo Animai e non tutti gli 
animali abbaiano. Ora ci chiediamo se invece un'istruzione di questo tipo può essere valida: 

Animai [] a = new Dog [10]; 

ovvero se un array di Dog è un array di Animai. Qui iniziamo ad avere qualche difficoltà: l'istruzione 
precedente compila perfettamente ma presenta un grosso problema che cerchiamo di spiegare. In 
questo caso a è un riferimento a un array di Animai che in questo momento sta referenziando un array 
di Dog. Questo significa che un'istruzione del tipo 

a [ 0 ] = new Dog ( ) ; 

è perfettamente valida e infatti compila e viene pure eseguita correttamente. Consideriamo ora però 
questa istruzione 

a [1] = new Cat () ; 

dove anche cat è una classe che estende Animai in quanto anche un gatto è un animale. Anche qui 
il codice compila in quanto a [ 1 ] è un riferimento a un oggetto di tipo Animai che nell'istruzione 
precedente viene valorizzato con un riferimento a un cat che è un Animai. Il problema sta però 
nell'oggetto referenziato, che è un array di Dog, per cui stiamo cercando di inserire un cat in un array 
di Dog provocando un errore in esecuzione. In particolare l'errore è il seguente: 

Exception in thread "main" java . lang . ArrayStoreException : 
uk . co . massimocarli . javacourse . oo . generics . Cat at 

uk . co . massimocarli . javacourse . oo . generics . GenericTest3 .main (GenericTest3 . java : 13 ) 

Come nel caso delle liste precedenti, si ha un errore in fase di esecuzione che non si era previsto in 
fase di compilazione. Facciamo allora un ulteriore passo avanti e chiediamoci se la prossima 
assegnazione è corretta, se compila e, in caso affermativo, se viene eseguita correttamente: 

List<Animal> a = new LinkedList<Dog> ( ) ; 

Ci chiediamo se una List di Animai è una List di Dog. Questa volta la risposta è no. Una lista di 
cani non è una lista di animali Questo perché, se lo fosse, analogamente a quanto visto prima, 
attraverso il riferimento alla lista di animali riusciremmo a inserire un gatto all'interno di una lista di 
cani Questo però ora è riconosciuto dal compilatore, che ci notifica un errore che quindi possiamo 
correggere, ma come? Se abbiamo bisogno di un tipo di riferimento che ci permetta di referenziare sia 
una lista di cani sia una lista di gatti o di altro la sintassi da utilizzare è questa: 

Lìst<?> a = new LinkedList<Dog> ( ) ; 

e quindi le seguenti istruzioni diventano perfettamente lecite: 

Lìst<?> listaAnimali = new LinkedList<Dog> ( ) ; 
lìstaAnimali = new LinkedList<Animal> ( ) ; 
listaAnimali = new LinkedList<Cat> ( ) ; 
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con un prezzo che è quello di non poter inserire ma solamente estrarre. Questo perché, per quanto 
detto, se potessimo inserire avremmo la capacità di aggiungere, attraverso l'astrazione, un oggetto di 
un tipo all'interno di ima lista di un altro tipo. Tramite una List<?> non potremmo inserire un Dog in 
quanto la lista referenziata poteva essere di cat o di un qualunque altro tipo. Bene, ma se possiamo 
estrarre di che tipo sarà l'oggetto estratto? Anche qui la risposta è un salomonico "non lo sappiamo", 
ma non siamo completamente ignoranti Qualunque sia il tipo dell'oggetto che andiamo a estrarre si 
tratterà sicuramente di qualcosa che possiamo associare a un riferimento di tipo ob ject, in quanto tutti 
gli oggetti in Java sono istanze di una classe che direttamente o indirettamente estende la classe 
Ob ject. Ecco che un'istruzione di questo tipo è perfettamente valida: 

List<?> lista = 

Object item = lista . get ( 0 ) ; 

Possiamo però fare ancora meglio perché nel nostro caso non stiamo lavorando con classi 
qualunque ma con animali, ovvero oggetti che estendono la classe Animai. Possiamo quindi dire che 
degli oggetti che andiamo a estrarre dalla lista qualcosa alla fine conosciamo. Non sappiamo 
esattamente di che tipo sono ma sappiamo sicuramente che sono animali. Il precedente metodo 
print o può essere scritto nel seguente modo: 

public static void print (List<? extends Animal> list) { 
for (Animai item: list) { 

System. out .println (item) ; 

} 

} 

Attraverso la notazione List<? extends Animai> indichiamo un riferimento a una lista di oggetti 
che non sappiamo ancora di che tipo siano (se sono Dog, cat o altro) ma che sappiamo di certo sono 
specializzazioni della classe Animai. Da un lato questo ci permette di restringere i tipi di parametri che 
possono essere passati al metodo e dall'altro di avere qualche informazione in più sugli oggetti che 
possiamo estrarre che ora, qualunque cosa siano, possono sicuramente essere assegnati a un 
riferimento di tipo Animai come fatto nel nostro enhancedfor. In questo caso possiamo anche 
inserire qualcosa? Purtroppo ancora no, perché sappiamo che si tratta di animali ma non sappiamo di 
che tipo. Esiste ancora, per esempio, il pericolo di inserire Dog dove ci sono cat. Ci chiediamo allora 
se esista una notazione simile alla precedente, ma che ci permetta F inserimento di oggetti all'interno di 
una lista. Certo; tale espressione è la seguente: 

List<? super Animal> lista; 

In questo caso il significato è quello di riferimento a una lista di Animai 0 di sue superclassi, che in 
questo caso può essere solo la classe object. Per fare un esempio diverso, il riferimento 

List<? super Dog> lista; 

permette di referenziare una lista di Dog, oppure di Animai oppure di object. Prendendo sempre 
questo ultimo esempio, in una lista come questa possiamo anche inserire, e precisamente possiamo 
inserire istanze di Dog o di sue classi figlie. Esse saranno in effetti sempre Dog, oppure Animai oppure 
object nel peggiore dei casi. Ma dove si utilizzano espressioni di questo tipo? Non entreremo nei 
dettagli ma pensiamo per esempio al caso in cui dovessimo ordinare un insieme di questi oggetti 
attraverso un comparator. Un particolare com P arator<T> è un oggetto in grado di riconoscere se un 
oggetto di tipo t è maggiore, uguale o minore di un altro dello stesso tipo. Supponiamo di voler 
creare un metodo di ordinamento di oggetti di tipo t contenuti in una lista attraverso questo tipo di 
comparator. La firma di questo metodo, che si dice generico, sarà del tipo: 

public <T> void sort (List<T> list, Comparator<T> comp) 
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La definizione di <t> all'inizio del metodo indica appunto che si tratta di un metodo con parametri 
generici e ci consente di descrivere la relazione tra essi II significato in questo caso è quello di un 
metodo che permette di ordinare oggetti di tipo t contenuti in una lista attraverso un comparator in 
grado di ordinare oggetti dello stesso tipo t. Per stare sul concreto, una List<Dog> potrà essere 
ordinata solo se si ha a disposizione un com P arator<Dog> . In realtà sappiamo che un Dog è un Animai 
per cui potremmo ordinare la lista di Dog anche se avessimo a disposizione un com P arator<Animai> o 
un com P arator<ob ject>. Un com P arator<Animai> sarebbe in grado di ordinare il Dog in quanto 
Animai perderebbe le sue caratteristiche di cane, ma questo va stabilito in fase di analisi del metodo 
che stiamo scrivendo. Nel caso in cui decidessimo di permettere questa cosa, la firma del metodo 
diventerebbe la seguente: 

public <T> void sort (List<T> list, Comparator<? super T> comp) 

Se poi volessimo ampliare ulteriormente, potremmo scrivere lo stesso metodo nel seguente modo: 

public <T> void sort (List<? extends T> list, Comparator<? super T> comp) 

Abbiamo quindi capito come i generics siano uno strumento molto potente e da usare a fondo nello 
sviluppo delle nostre applicazioni, più come utilizzatori che come realizzatori di classi generiche. Per 
completezza vogliamo concludere con un paio di esempi molto semplici e allo stesso tempo utili II 
primo riguarda la possibilità di creare una classe che funge da Hoider di un oggetto di tipo t: 

public class Holder<T> { 

private final T mData; 

public Holder(T data) { 
this. mData = data; 

} 

public T getDataO { 
return mData; 

} 

} 

Attraverso questo semplice codice abbiamo creato una classe immutabile di nome Hoider in grado 
di memorizzare il riferimento a qualunque oggetto di tipo t. Mediante questa classe possiamo scrivere 
delle righe del codice di questo tipo: 

public static void main (String [ ] args) { 

Holder<String> hString = new Holder<String> ( "String" ) ; 
String str = hString . getData ( ) ; 

Holder<Integer> hlnteger = new Holder<Integer> (10) ; 
Integer vai = hlnteger . getData ( ) ; 

} 

Notiamo come sia semplice e utile creare istanze di Hoider che incapsulano valori di tipo diverso 
che poi è possibile ottenere attraverso il corrispondente metodo getData ( ) . 

L'ultima osservazione riguarda quella che si chiama type inference e che consiste nel far ritornare a 
un metodo un oggetto di tipo dipendente da quello della variabile a cui lo stesso viene assegnato. 
Andiamo anche qui sul concreto. Quando tratteremo le activity vedremo come ottenere il riferimento 
a un elemento del corrispondente layout attraverso un metodo del tipo 

protected View f indViewByld (int viewld) ; 

Si tratta di un metodo che, dato un identificatore di tipo intero, ritorna una particolare 
specializzazione della classe view, che può essere un Button, un Textview, una EditText e così via. 
Vedremo come vi siano spesso delle istruzioni del tipo: 

Textview output = (Textview) findViewByld (R . id . output ) ; 

33 



Quello che vogliamo lare è eliminare il fastidioso cast e tare in modo che il tipo di view ritornata dal 
metodo che chiamiamo getviewo sia quello della variabile a cui viene assegnato. Osserviamo la 
seguente implementazione di un metodo statico che supponiamo essere della classe UT: 

public static <T extends View> T f indViewByld (Activity act, int viewld) { 
// Otteniamo il ViewGroup dell ' activity 
View containerView = act . getwindow ( ) . getDecorView ( ) ; 
return findViewByld (containerView, viewld); 

} 

Attraverso l'utilizzo di un metodo generico possiamo tare in modo di scrivere l'istruzione 
precedente nel seguente modo: 

TextView output = (UI . findViewByld (activity , R . id. output ) ; 

Attenzione: si tratta solamente di una semplificazione che non garantisce che l'oggetto ritornato sia 
effettivamente del tipo voluto. Lo stesso problema si aveva comunque anche nel caso precedente, ma 
così si evita il cast. 

Conclusioni 

In questo primo capitolo abbiamo posto le basi per poter affrontare il nostro progetto e iniziare a 
realizzare la nostra applicazione Android. Nella prima parte ci siamo occupati di cos'è Android: la sua 
architettura, la sua relazione con Java e quindi i suoi componenti principali. Si è trattato di 
un' infarinatura di quello che ci attende nelle prossime pagine. Nella seconda parte del capitolo ci 
siamo dedicati al linguaggio Java e agli aspetti che ci potranno essere più utili in ambito Android. Ora 
siamo davvero pronti, per cui mettiamoci al lavoro. 
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Capitolo 2 



Il progetto UGHO e la creazione 
dell'ambiente con Android Studio 



Come detto nell'Introduzione, questo libro vuole seguire un approccio molto pratico che fornisca i 
concetti fondamentali lasciando al lettore gli approfondimenti sulla documentazione ufficiale o 
attraverso gli altri miei testi dello stesso editore. 

In questo capitolo inizieremo a creare la nostra applicazione con il nuovo strumento annunciato 
all'ultima Google IO, ovvero Android Studio. 

Si tratta di un IDE basato su IntelliJ 

(http://developer.android.com/sdk/installing/studio.html) Specializzato nello Sviluppo di 

applicazioni Android. La versione che andremo a utilizzare è la prima disponibile, per cui nel momento 
in cui si legge avrà sicuramente avuto dei miglioramenti 

Non ci dilungheremo sul processo di installazione, ma passeremo velocemente alla descrizione 
dell'applicazione che vogliamo creare aggiungendo nuove funzionalità di volta in volta. Creeremo 
quindi il progetto con Android Studio illustrandone tutte le parti principali, concentrandoci sulla 
gestione di quelle che si chiamano risorse e che rappresentano una parte fondamentale di tutte le 
app Reazioni Android. 

In questa fase la nostra applicazione non visualizzerà molto di più di un'unica schermata, che sarà 
comunque il punto dipartenza per il capitolo successivo, dove affronteremo le activity e quindi la 
modalità di navigazione. 

Installazione di Android Studio e creazione del 

progetto 

Come accennato, non perderemo molto tempo nella descrizione di come installare questo nuovo 
IDE presentato alla Google IO 2013 e che possiamo scaricare all'indirizzo 

http : //developer . android . com/ sdk/installing/ studio . html. 

La modalità di installazione dipenderà dalla piattaforma utilizzata, ma si tratta sostanzialmente di un 
eseguibile che prowederà in modo automatico all'installazione dell'ambiente. Terminata la procedura, 
ci basterà selezionare la corrispondente icona, ottenendo la finestra mostrata nella Figura 2.1. 
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| Welcome to Android Studio 



Recent Projects 




Quick Start 



É3 


New Project... 






Import Project 






Open Project 




vcs 


Check out from Version Control 






Configure 
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Docs and How-Tos 





Android Studio 0.1 Build 130.677228. Check for updates now. 



Figura 2.1 Primo avvio di Android Studio. 

Notiamo come nella parte sinistra vi sia un classico elenco degli ultimi progetti (per noi ancora 
nuovo), mentre nella parte destra c'è un elenco di opzioni tra cui la creazione di un nuovo progetto 
che andremo a selezionare ottenendo la finestra nella Figura 2.2; compiliamola con le nostre 
informazioni, che ci accingiamo a descrivere nel dettaglio. 

Innanzitutto ogni applicazione ha un proprio nome che nel nostro caso è UGHO (User Generateci 
HOroscope). Per il momento utilizziamolo per quello che è, ovvero un nome. Il secondo valore è il 
nome del modulo, che invece è un concetto specifico di questo IDE. In pratica un modulo viene 
definito come una componente funzionale che può essere compilata, eseguita, testata e privata dei bug 
in modo autonomo. Se il nostro progetto utilizza una libreria, questa potrebbe essere pensata come 
modulo con i propri sorgenti, le proprie risorse, le proprie classi di test e così via. Un progetto 
potrebbe quindi essere composto da più moduli da cui si dice che dipende. I moduli rappresentano il 
meccanismo con cui IntelliJ, e quindi Android Studio, gestisce le dipendenze. Un progetto Android, 
come vedremo, ha ima struttura particolare, per cui la personalizzazione creata da Google non ha 
fatto altro che creare un tipo specifico di modulo che si chiama Android Module. 
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Module name: 
Package name: 
Project location: 
Minimum required SDK: 
Target SDK: 
Compile with 
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UCHO 

uk.co.massimocarli.android.ugho 
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API 7: Android 2.1 (Eclair) 



API 16: Android 4.1(Jelly Bean) 



API 17: Android 4.2 (jelly Bean) 



Holo Light with Dark Action Bar 



•S Create custom launcher icon 
>/ Create activity 

Mark this project as a library 



Description 

The package name must be a unique identifier for your application. It is typically not shown to 
users, but it must stay the same for the lifetime of your application: it is how multiple versions 
of the same application are considered the "same app". This is typically the reverse domain 
name of your organization plus one or more application identifiers, and it must be a valid Java 
package name. 



(7) Qcancel Previous I Next 

Figura 2.2 Creazione del progetto. 

Avremo modo di approfondire più avanti questo e altri concetti alla base della gestione a moduli; 
per il momento diamo al modulo che rappresenta il nostro progetto lo stesso nome del progetto: 
UGHO. 

L'informazione successiva riguarda il nome del package associato alla nostra applicazione. Si tratta 
di un concetto molto più importante di quello che sembra, in quanto ogni applicazione Android può 
essere associata a uno e un solo package, il quale dovrà rimanere lo stesso per tutta la sua vita. Il 
package è quella caratteristica della nostra applicazione che l'identifica univocamente all'interno del 
Play Store, nel quale non ci potranno mai essere due applicazioni associate a uno stesso package. 

NOTA 

Quello descritto è un noto antipattern nello sviluppo Android. Una volta che si decide di realizzare 
una propria applicazione, è bene verificare la disponibilità del package voluto sul Play Store e quindi 
"bloccarlo" magari con un'applicazione dummy non pubblica. Questo evita spiacevoli sorprese nel 
momento del rilascio effettivo. 

Il nome del package dovrà seguire le convenzioni previste da Java, ovvero dovrà essere composto 
da parole minuscole non riservate divise dal punto. Nel caso di Android non potremo utilizzare dei 
package del tipo com.exampie o com. android. Le convenzioni vogliono poiché il package sia legato 
al dominio della nostra azienda. Se il nostro dominio è del tipo miodomnio . it il package dovrà iniziare 
per it.miodominio ovvero al contrario. 

La sezione successiva è quella relativa agli API Level che la nostra applicazione è in grado di 
supportare. Quello di API Level è un altro concetto fondamentale, in quanto rappresenta una 
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particolare versione dell'SDK della piattaforma. A ogni versione rilasciata corrisponde un API Level 
progressivo che dovrebbe (finora è sempre stato così) garantire la retrocompatibilità. Questo significa 
che un'applicazione realizzata per un valore di API Level pari a 7 (Eclair) potrà essere eseguita senza 
problemi in dispositivi che utilizzano una versione uguale o superiore. Come possiamo notare nella 
figura, il nostro progetto definisce tre diversi valori di API Level supportati In particolare il primo, 
quello definito come minimum, rappresenta appunto la versione minima della piattaforma di cui la 
nostra app Reazione necessita per un corretto funzionamento. 
NOTA 

Il valore di API Level, insieme a quelle che si chiamano feature e alle dimensioni dei display 
supportati, rappresenta uno dei valori utilizzati dal Play Store per determinare se un'applicazione 
può essere eseguita o meno su un particolare dispositivo; in caso contrario, non verrà da questo 
visualizzata tra quelle disponibili nello Sfora 

Nel nostro progetto abbiamo deciso di supportare come minima la versione 2. 1 della piattaforma. 
Se andiamo a osservare le ultime statistiche all'indirizzo 

http : / / developer . android . com/about / dashboards/ index . html. Notiamo come la nostra decisione 

ci permetta di coprire la quasi totalità dei dispositivi sul mercato.Più sono le versioni supportate, 
maggiore è il numero di utenti potenziali per la nostra applicazione. 

Lo svantaggio consiste invece nell'impossibilità di utilizzare le feature specifiche delle ultime versioni 
costringendoci a ricorrere ad alcuni accorgimenti che complicano lo sviluppo. Vedremo 
successivamente, durante lo sviluppo delle varie funzionalità, se aumentare o meno questo valore. 

Il secondo API Level che impostiamo è quello denominato Target, che caratterizza la versione da 
considerare come attiva durante lo sviluppo e che è stata considerata per il testing e il debug. 
Ciascuna versione dell'SDK ha infatti introdotto nuovi elementi di configurazione e nuove feature. 
Attraverso questa configurazione stiamo dicendo che per noi gli strumenti a disposizione sono quelli 
specifici dell'API Level, 16 ovvero la 4.1 di JettyBean. Questa configurazione potrebbe sembrare in 
contrasto con la precedente: se la nostra applicazione è stata realizzata con la versione 16 come fa a 
funzionare sulla versione 7 della piattaforma? In realtà quello che stiamo dicendo con le configurazioni 
precedenti è che la nostra app Reazione è stata reaRzzata e testata nei dispositivi con API Level 16 e 
superiori ma che non utiRzza feature particolari che ne Rnpediscono l'esecuzione in dispositivi con API 
Level da 7 in su. 

Ad aggiungere ulteriore confusione vi è poi un altro possibile valore di API Level che viene Ridicato 
come quello utiRzzato per la compilazione del nostro progetto. Ma che senso ha svikippare 
un' app Reazione con un API Level di riferimento e poi compilarla con un API Level diverso? In realtà 
la documentazione non dice nuUa al riguardo e al momento il valore Risento non viene usato in alcun 
file di configurazione. Possiamo solo dedurre che si tratti di qualcosa legato al nuovo sistema di 
bufldRig che si chiama Gradle, che avremo comunque modo di approfondire successivamente. 

LRiformazione richiesta successivamente è queRa relativa al tema utflizzato, un altro importante 
concetto a cui dedicheremo parte del testo. Si tratta fondamentabnente di un particolare tipo di 
risorsa che permette di configurare, in modo dichiarativo, alcuni aspetti legati al look &feel 
deR'appRcazione. È queRo strumento che ci permetterà di decidere se sarà presente un'ActionBar, 
quale sarà fl suo colore, la modafità di rappresentazione dei pulsanti e così via. Se volessimo fare 
un'analogia con il Web potremmo dire che si tratta di qualcosa con funzionaRtà simfle a queRa di un 
CSS in una pagina HTML. Vedremo come fl layout descriverà l'flisieme dei componenti di ima 
schermata che i diversi temi ci permetteranno di speciafizzare nette loro informazioni di visuafizzazione. 
Nel nostro progetto stiamo utilizzando i tempi di default per fl target Holo Light, che utflizza 
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un'ActionBar di colore scuro. Questa configurazione è tutt'altro che banale in quanto il tema indicato 
è stato aggiunto dalla versione 14 dell' API Level mentre noi abbiamo indicato come versione minima 
supportata quella dell' API Level 7. Questa osservazione solo per mettere in evidenza quella che è 
una delle principali problematiche nella gestione delle risorse che ci permetterà di definirne diverse 
versioni selezionate in modo automatico a seconda delle caratteristiche del particolare dispositivo. 
Vedremo quindi come utilizzare il tema indicato se disponibile oppure come scalare su altri temi nel 
caso di dispositivi con API Level precedenti. 
NOTA 

Come possiamo notare la piattaforma ha raggiunto ormai un'evoluzione non trascurabile, la quale ha 
portato a una curva di apprendimento più lunga. Il lettore comunque non si perda d'animo: 
tratteremo nel dettaglio ciascuno degli aspetti solo accennati in questa fase. 

Il flag successivo ci permette di decidere se creare l'icona dell'applicazione con il nostro IDE o se 
gestirla in modo diverso. Nel nostro caso la selezioniamo allo stesso modo della casella di controllo 
relativa alla creazione o meno della prima activity. Dedicheremo un capitolo intero alla creazione e 
gestione delle activity (che chiameremo in alternativa "attività") che rappresentano sostanzialmente una 
schermata della nostra applicazione. Selezionando la casella di controllo vedremo come l'IDE si 
preoccupi di generare per noi in modo automatico un'attività e il relativo documento di layout. 

L'ultima casella di controllo permette invece di indicare che il modulo che stiamo realizzando è una 
libreria che potrà essere quindi inclusa in più di un progetto. Nel nostro caso non utilizziamo, per il 
momento, alcuna libreria, per cui lasciamo non selezionatala casella di controllo e premiamo 
finalmente il pulsante Next. 

Creazione dell'icona 

Nella schermata precedente abbiamo selezionato la casella di controllo relativa alla creazione 
dell'icona associata alla nostra applicazione. Per questo motivo, la selezione del pulsante Next ha 
portato alla visualizzazione della schermata nella Figura 2.3. In questa fase non ci dilunghiamo sulla 
creazione effettiva dell'immagine, che lasciamo al lettore come divertimento, quanto piuttosto su un 
aspetto fondamentale di tutte le risorse Andro id a cui abbiamo accennato in precedenza. Ogni risorsa, 
in questo caso un'immagine, può essere specializzata in base a precise caratteristiche del dispositivo 
che andrà a eseguire l'applicazione. In questo caso, quello che chiameremo qualificatore fa 
riferimento alla risoluzione del display, che in Andro id è stato classificato in diverse categorie tra cui 
quelle indicate come mdpi, hdpi, xhdpi ed xxhdpi, rispettivamente media, alta, altissima ed extra 
altissima. Sempre nella logica di un ottimale sfruttamento delle risorse di un dispositivo è intatti 
importante utilizzare le risorse più adatte. Un dispositivo di risoluzione classificato come altissima 
dovrà visualizzare immagini con la stessa risoluzione; la stessa immagine su un dispositivo classificato 
come di media risoluzione costringerebbe lo stesso a operazioni di adattamento o resize che 
potrebbero essere dispendiose, oltre che portare a risultati non ottimali Come detto, lasciamo 
"giocare" il lettore con il generatore di immagini dell'applicazione e proseguiamo con la nostra 
descrizione selezionando il pulsante Next. 
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Figura 2.3 Creazione dell'icona per la nostra applicazione. 



Creazione dell'attività principale 

Nella prima schermata abbiamo selezionato la casella di controllo relativa alla creazione 
dell' activity principale della nostra applicazione, per cui a questo punto avremo la visualizzazione della 
finestra nella Figura 2.4. 
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Figura 2.4 Creazione dell'activity principale dell'applicazione. 

In questa fase il plug-in ci dà la possibilità di selezionare il particolare layout tra alcuni disponibili. 
Oltre a quello denominato Blank Activity che andremo a selezionare, ve ne sono altri, tra cui quello 
per la visualizzazione di una schermata a dimensione piena, quello per la creazione di una maschera di 
login e quello caratteristico di un'applicazione per tablet. Vedremo a tempo debito come utilizzare 
questi altri specifici layout; per il momento selezioniamo il pulsante Next ottenendo la schermata nella 
Figura 2.5. 

Abbiamo già accennato a come un' activity rappresenti una particolare schermata della nostra 
app Reazione. Nel prossimo capitolo vedremo come ciascuna di esse venga descritta da una 
particolare specializzazione, diretta o indiretta, della classe andrò id . app .Activity, che potrà 
delegare la descrizione della UI a ima particolare risorsa di layout descritta da un documento XML. 
In questa finestra non facciamo altro che specificare il nome della classe che descrive l'attività e il 
nome del documento XML di layout. In questa fase è importante ricordare che la classe è relativa al 
package che abbiamo associato al progetto. Il documento di layout non ha limitazioni particolari se 
non quelle delle normali regole di nomenclatura di Java. Il menu a tendina relativo al Navigation Type 
ci permetterà di generare in modo automatico del codice per la navigazione tra attività diverse e 
dipenderà dal tipo di layout specificato nel passo precedente. Per il momento non selezioniamo alcun 
valore. 
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Figura 2.5 Nome dell'activity e relativo documento di layout. 



Siamo così giunti alla fine del wizard di creazione di un progetto. Come visto vi sono moltissimi 
concetti, che andremo a esaminare di volta in volta. Per il momento accontentiamoci di premere 
finalmente il pulsante Finish. 



Che cosa è stato realizzato 

A questo punto l'IDE inizierà a caricare alcune librerie di supporto relative a Gradle, il nuovo 
sistema di building utilizzato per Andro id in questa versione adattata di IntelliJ chiamata Andro id 
Studio. Al termine del caricamento otteniamo una schermata vuota nella quale possiamo comunque 
notare alcuni pulsanti lungo il bordo sinistro e inferiore. Si tratta di pulsanti che permettono 
l'attivazione di alcune parti dell'editor. Per esempio, selezionando il pulsante indicato come 1 .'Project 
nella Figura 2.6 si ha la visualizzazione della struttura del progetto nella Figura 2.7. 

Facendo attenzione notiamo come ciascuna parte dell'editor sia caratterizzata da un nome e da un 
numero che nella figura è sottolineato. Si tratta del valore relativo alla scorciatoia che permette 
l'attivazione o meno del corrispondente elemento. Nel caso della struttura del progetto, l'attivazione 
sarà possibile attraverso la selezione del pulsante con il mouse o premendo Alt+1 su Windows o 
Cmd+1 su Mac. 
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Figura 2.6 Pulsanti per l'attivazione di parti dell'editor. 
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Figura 2.7 Struttura del progetto in Android Studio. 



In alto a sinistra notiamo la presenza del nome del progetto, che è la radice di una struttura ad 
albero che ci permetterà di raggiungere ogni elemento del progetto attraverso un menu che si chiama 
Project. 

Aprendo la finestra per la visualizzazione del nostro progetto otteniamo quello nella Figura 2.7, nel 
quale sono visualizzate due parti principali; il progetto vero e proprio e le librerie esteme intese come 
quelle librerie di cui il progetto ha bisogno per la propria esecuzione. Di fianco al nome del progetto è 
riportato il percorso assoluto dove lo stesso è memorizzato. 

La prima cartella associata al nostro progetto si chiama .idea, e contiene una serie di configurazioni 
relative al nostro progetto. Osservando per esempio la Figura 2.8, notiamo come siamo presenti 
alcune configurazioni relative agli encoding supportati, alle dipendenze, al compilatore utilizzato ai 
moduli installati e così via. Si tratta quindi di configurazioni del progetto che è comunque bene 
includere, come vedremo dopo, nella parte da sottoporre a versioning. L'unica eccezione riguarda il 
file workspace . xml, il quale contiene delle configurazioni che sono legate al particolare sviluppatore, 
tra cui la directory di installazione, l'account per il tool di versioning e altro ancora. Si tratta comunque 
di una cartella che non andremo a toccare se non in casi specifici 
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Figura 2.8 II contenuto della cartella di configurazione .idea. 



La cartella successiva si chiama gracile e contiene tutto ciò che servirà per l'esecuzione degli script 
di Gradle. Questo avviene attraverso quello che si chiama Gracile wrapper, le cui classi e 
configurazioni sono appunto contenute in questa parte del progetto, come possiamo vedere nella 
Figura 2.9. 

Si tratta di uno script batch in Windows o di uno script di shell in altri ambienti, che permette di 
scaricare Gradle e quindi eseguire l'eventuale script dibuild. Anche in questo caso ci chiediamo se si 
tratti di un qualcosa che dobbiamo mettere sotto versioning oppure no. In realtà questo non è 
obbligatorio ma è comunque consigliato, in modo da permettere a chiunque esegua il clone del nostro 
progetto di eseguirne ilbuild senza dover necessariamente installare precedentemente l'ambiente di 
Gradle. In questo modo il tutto è automatico e nella versione corretta. 

Eccoci finalmente a quella che è la cartella più importante, quella che contiene il nostro progetto 
che abbiamo espanso nella Figura 2.10. Essa è composta da tre ulteriori cartelle e da un file di nome 
build. gradle che contiene le informazioni per il build della nostra applicazione e che descriviamo 
brevemente per primo. 
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Figura 2.9 II Gradle wrapper per l'utilizzo di Gradle per il build dell'applicazione. 
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Figura 2.10 Struttura del progetto Android. 



Come abbiamo accennato, Gradle è il nuovo sistema di building che i progettisti di Android hanno 
deciso di adottare per la sua grande flessibilità. Attraverso questo strumento si può infatti definire un 
proprio linguaggio dinamico (DSL, Domain Specific Language) che permetta di stabilire tutte le 
regole di build fino a realizzare diverse versioni dello stesso progetto in base a particolari parametri 
Con la grande frammentazione dei dispositivi non è intatti cosa rara dover realizzare diverse versioni 
di un' app Reazione in base alle caratteristiche di un qualche dispositivo. Lo stesso vale qualora occorra 
firmare l'applicazione con certificati diversi, come quello di debug o quello di produzione, come 
vedremo quando andremo finalmente a eseguire la nostra applicazione. 

In questa fase non andremo a descrivere nel dettaglio come funziona Gradle ma daremo solamente 
qualche informazione che ci permetta di capire qual è lo scopo di questo strumento. Il file 
build.gradle creato per il nostro progetto è questo: 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/maven2' } 

} 

dependencies { 

classpath 1 coiti, android . tools . build : gradle : 0 . 4 . 1 ' 

} 
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} 

apply plugin : ' android ' 

dependencies { 

compile f iles ( ' libs/ android-support-v4 . jar ' ) 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdkVersion 7 
targetSdkVersion 16 

} 

} 

nel quale abbiamo evidenziato come venga utilizzato un plug-in di nome android che è stato 
realizzato come estensione di un altro di nome java. Si tratta in sostanza di estensioni del linguaggio 
offerto da Gradle per la gestione delle operazioni di build di Java e quindi di Android. È bene inoltre 
sottolineare come, nel momento in cui si scrive, il plug-in android non sia ancora completo di tutti gli 
strumenti ma comunque abbia ima maturità tale da permetterci di realizzare il nostro progetto. 

NOTA 

In questo testo non tratteremo infatti argomenti quali il testing e particolari configurazioni di progetti 
composti da più moduli di natura diversa che collaborano tra loro. Per questo si rimanda ad altri 
miei testi pubblicati con lo stesso editore. 

La prima parte è caratterizzata dall'elemento buìidsoript {...}, che contiene alcune configurazioni 
caratteristiche dei diversi progetti Java, tra cui la dichiarazione del repository remoto di Maven e la 
dipendenza verso il codice relativo al plug-in stesso. Si tratta della dipendenza non relativa al progetto 
ma al tool che eseguirà lo script di Gradle. 

NOTA 

Maven è uno dei tool del mondo Apache utilizzato in moltissimi casi nella gestione dei progetti e in 
particolare delle dipendenze tra i vari componenti e le librerie. Nel caso di Gradle vengono utilizzate 
funzionalità di Maven, di Ant e di Ivy. 

Le dipendenze del particolare modulo sono invece definite attraverso l'elemento 
dependencies {...}. In questo caso notiamo la definizione di ima dipendenza verso una libreria che 
sarà molto importante e che prende il nome di compatibility library. Si tratta di ima libreria che è 
stata introdotta per ridurre la frammentazione tra i diversi dispositivi cercando di uniformare l'insieme 
delle classi disponibili nelle diverse versioni Per fare un esempio, nel Capitolo 4 vedremo come 
utilizzare i fragment, che semplificheranno la realizzazione delle applicazioni per i tablet. Si tratta però 
di strumenti che sono stati aggiunti dalla versione 3 .0 della piattaforma che quindi non potrebbero 
essere utilizzati nelle versioni precedenti Attraverso questa libreria si potranno invece utilizzare queste 
classi anche in versioni precedenti fino alla 1.6. Tornano al nostro file di build, notiamo come nel 
nostro caso non si faccia altro che definire la dipendenza con il JAR di questa speciale libreria. 

Infine vediamo quella associata a un elemento di nome androidi . . . }, che conterrà tutte le 
definizioni specifiche dell'omonimo plug-in. Attraverso opportune implementazioni sarà possibile 
realizzare diverse versioni della nostra applicazione che si differenziano, per esempio, per alcune 
funzioni di test o di tracciamento o per la presenza di alcuni permessi che non si intendono utilizzare in 
produzione e così via. Per ciascuna di queste versioni saranno definibili le proprie classi risorse e così 
via. Il plug-in permette comunque la creazione di almeno due di queste versioni relative alla versione 
di debug e a quella di produzione (release). Nel nostro caso utilizziamo la configurazione di default 
che ci consente di specificare, attraverso l'elemento defauitconfig{ . . . } le informazioni relative agli 
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API Level supportati come tatto in tàse di creazione del progetto con il relativo wizard all'inizio del 
capitolo. 

I sorgenti e le risorse del progetto 

Come detto, non ci dilunghiamo nella descrizione di questi file di build, per i quali probabilmente 
servirebbe un testo apposta, ma passiamo alla descrizione della parte per noi più importante: quella 
che definisce le classi e le risorse del nostro progetto ovvero della cartella src nella Figura 2.11. 
All'interno ài src abbiamo la cartella di nome mairi, che contiene a sua volta due fondamentali cartelle 
di nome java e res. La prima conterrà tutte le classi Java del nostro progetto mentre la seconda 
conterrà quelle che si chiamano risorse e che esamineremo nel dettaglio successivamente. Per il 
momento consideriamo le risorse come particolari file di configurazione o immagini accessibili dal 
nostro codice ma dotati della possibilità di essere opportunamente selezionati in base al particolare 
dispositivo che esegue la nostra applicazione. Come esempio è sufficiente osservare le cartelle del 
tipo drawable, che contengono sostanzialmente elementi che possono essere visualizzati sul display 
(per esempio immagini ma non solo) che si differenziano per un codice che identifica una particolare 
densità. Per essere sintetici vedremo come un dispositivo con display classificato di densità media 
(mdpi) sceglierà quelle particolari risorse contenute nella cartella drawable -mdpi, mentre uno 
classificato di densità altissima (xhdpì) sceglierà quelle contenute all'interno della cartella drawable- 
xhdpi. I criteri utilizzati dalla piattaforma nella selezione delle risorse da utilizzare prendono il nome di 
qualificatori. 

La selezione della risorsa opportuna per ogni dispositivo permette anche una gestione ottimale delle 
risorse. Pensiamo per esempio al caso in cui un dispositivo ha la necessità di effettuare il resize di 
un'immagine di dimensioni maggiori del dovuto. In questo caso il danno sarebbe doppio in quanto 
legato a uno spreco di memoria (immagine troppo grande) e di elaborazione (il resize), con 
conseguente esaurimento della risorsa a noi più cara, ovvero la batteria. 

Un altro fondamentale tipo di risorse a cui dedicheremo il Capitolo 5 sono i layout dei documenti 
XML che ci permetteranno di definire in modo dichiarativo le schermate della nostra applicazione. In 
questa fase ci concentreremo solamente su tre aspetti fondamentali del progetto creato: 
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Figura 2.11 Struttura del progetto Android. 



• la risorsa di tipo layout create; 

• la classe relativa all'activity; 

• il file di Configurazione AndroidManifest.xml. 

Le risorse di tipo layout sono di fondamentale importanza in quanto ci permettono di definire in 
modo dichiarativo le interfacce della nostra applicazione, quella che viene spesso indicata come UI 
{User Interface). Diciamo intanto che si tratta di una risorsa che potrà essere qualificata. Vedremo 
più avanti i possibili qualificatori ma è tacile intuire come questi possano essere quelli relativi 
all'orientamento del dispositivo. Si potrà quindi tare in modo di avere UI diverse non solo in base alle 
dimensioni dei display ma soprattutto in base al tatto che il dispositivo sia in posizione portrait 
(verticale) o landscape (orizzontale). Per il momento prendiamo quello che è stato realizzato 
automaticamente dal nostro plug-in in fase di creazione del progetto. Selezioniamo il file di nome 
activity_main . xml nella cartella src/main/resAayout ottenendo la visualizzazione di alcune finestre 
come nella Figura 2.12. 

Come possiamo osservare, l'interfaccia dell'IDE è divisa sostanzialmente in tre colonne, dove 
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l'ultima è suddivisa a sua volta in due righe. La prima colonna è associata di delàult a un pulsante di 
nome Palette e contiene tutti i componenti visuali che possiamo trascinare all'interno della preview 
dell' interfaccia nella parte centrale; questa contiene, nella parte bassa, due schede, di nome Design e 
Text. La prima è selezionata di delàult e permette appunto la visualizzazione di una preview, mentre la 
seconda permette di vedere il codice sorgente XML. 
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Figura 2.12 La gestione dei layout nell'editor. 

Prima di vedere come appare questo documento XML, notiamo come nella parte destra in alto vi 
sia la corrispondente visualizzazione ad albero. Tutti gli elementi definiti all'interno del documento di 
layout vengono visualizzati in modalità gerarchica. Questo tool è utile nel caso in cui sia necessario 
vedere quali componenti ne contengono altri e così via. Nella parte destra inferiore abbiamo infine il 
pannello delle proprietà. Selezionando un componente si può infatti modificarne le proprietà nella 
modalità ormai classica di qualunque IDE. 

Una delle novità di questo IDE rispetto a quello in eclipse si può osservare selezionando la scheda 
Text (Figura 2.13). Come possiamo notare l'interlàccia cambia ancora e mostra nella parte sinistra il 
codice sorgente del layout e nella parte destra ancora una preview del risultato. Questa volta si tratta 
però di una preview più completa in quanto ci consente di selezionare il tipo di display per i device più 
comuni Nella Figura 2.13, per esempio, viene visualizzato il risultato nel caso diunNexus 4 ma, 
utilizzando la tendina nella parte in alto a sinistra, è possibile scegliere altri tipi di display oppure 
visualizzarli tutti contemporaneamente attraverso l'opzione Preview Ali Screen Site (evidenziata nella 
Figura 2.14) con il risultato mostrato nella Figura 2 . 1 5 . E interessante come modificando il sorgente 
del layout si ottenga un'immediata modifica della corrispondente preview. 

Si tratta di una funzione molto importante che permette di ridurre notevolmente il tempo sui 
dispositivi reali; era infatti facile incappare spesso in UI non volute su particolari tipologie di 
dispositivi Inoltre possiamo selezionare un elemento nella preview e il cursore verrà posizionato 
automaticamente nel punto corrispondente nel sorgente nella parte sinistra. Si tratta di lùnzioni che alla 
lunga risulteranno molto utili Vedremo che lo stesso strumento si potrà utilizzare per testare le UI a 
seguito della modifica di altri qualificatori classici come quello della lingua, dell'orientamento e della 
versione diAPI Level disponibile. 
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Figura 2.13 Visualizzazione del layout e della relativa preview. 
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Figura 2.14 Tutti i display che è possibile testare. 
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Figura 2.15 Previewcon diversi dispositivi in diverse situazioni. 

Tornando al nostro documento di layout, notiamo come esso sia il seguente, nel quale abbiamo 
evidenziato alcuni elementi molto importanti; 

<RelativeLayout xmlns : android="http : // schemas . android . com/apk/res/ android" 
xmlns :tools="http: // schemas . android . com/tools" 
android: layout_width="match__parent " 
android: layout_height="match_jparent " 

android :paddingLeft="@dimen/activity_horizontal_margin" 

android : paddingRight=" @dimen/ activity_horizontal_margin" 
android: paddingTop=" @dimen/act ivity_verti cal_mar gin" 
android : paddingBottom= "@dimen/activity_vertical_margin" 
tools : context=" . MainActivity "> 

<TextView 

android : layout_width="wrap_content " 
android: layout_height="wrap_content " 
android: text="@string/hello_world" /> 

</RelativeLayout> 
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Innanzitutto notiamo come si tratti di un documento XML in cui gli elementi definiscono i diversi 
componenti grafici. Con <ReiativeLayout/> descriviamo un particolare contenitore che ci permetterà 
di disporre il contenuto attraverso alcune regole di posizionamento che dipenderanno dal layout 
stesso. In questo caso la posizione di ogni componente verrà specificata relativamente a quella del 
contenitore o degli altri elementi. La piattaforma mette a disposizione altre specializzazioni della classe 
ViewGroup, che vedremo nel Capitolo 5. Altre potranno poi essere realizzate in modo personalizzato. 
Analogamente, l'elemento <Textview/> ci permette di rappresentare quella che è sostanzialmente una 
label. La cosa fondamentale è comunque relative alle proprietà di questi componenti che vengono 
specificate attraverso opportuni attributi Per esempio, l'attributo android:text della Textview 
permette di specificare il testo da visualizzare al suo intemo. Attenzione però: il valore viene assegnato 
così: 

android: text=" @string/hello_world" 

con una notazione del tipo 

@<tipo risorsa>/nome risorsa 

Si tratta di un aspetto fondamentale di tutta l'architettura di Android che abbiamo voluto affrontare 
immediatamente. Dall'interno di un documento XML di layout, ma vedremo che lo stesso varrà nel 
caso di altri tipi di documenti, possiamo fare riferimento al valore di una risorsa attraverso una sintassi 
del tipo indicato. Se andiamo a cercare il valore di questa risorsa è sufficiente visualizzare il file 
strings .xml nella cartella srv/main/res/values/: 

<?xml version="l . 0" encoding="ut f-8 " ?> 
<resources> 

<string name="app_name" >UGHO</string> 

<string name="action_settings" >Settings</string> 

<string name="hello_world" >Hello world! </string> 
</ resources> 

Nel nostro caso, attraverso la sintassi @string/heiio_worid si fa riferimento al valore dato dalla 
stringa Hello worid ! . Il lettore si potrà a questo punto chiedere quale possa essere il motivo di 
questa sintassi; la risposta cade sempre sul concetto di qualificatori. Uno di questi, spesso associato 
alle risorse di tipo String, è quello legato alla lingua impostata nel dispositivo. Questo significa che 
potremmo definire la seguente risorsa da inserire all'interno del file strings . xml contenuto nella 
cartella srv/main/res/values-it/: 

.<?xml version="l . 0" encodìng="utf-8 " ?> 
<resources> 

<string name="action_settings" >Impostazìoni</string> 
<string name="hello_world" >Ciao Mondo ! </string> 

</ resources> 

A questo punto nel nostro layout faremo sempre e comunque riferimento alla risorsa identificata 
dalla sintassi @string/heiio_worid ma a runtime il dispositivo andrà a prendere il valore 
corrispondente alla lingua impostata. 

Come accennato si tratta di una caratteristica di tutte le risorse, come si può vedere nella seconda 
definizione evidenziata in precedenza: 

android : paddingLef t="@dimen/activity_horizontal_margin" 

dove la risorsa questa volta è di tipo dimension. In quel caso il qualificatore potrà essere 
eventualmente legato alle dimensioni del display oppure più probabilmente alla sua risoluzione. 

Bene, ma ima volta realizzato il nostro documento di layout che cosa ne facciamo? Per capirlo 
andiamo a visualizzare il sorgente della classe MainActìvity che il nostro plug-in ha generato su 
nostre istruzioni in fase di creazione del progetto: 
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package uk . co . massimocarli . android. ugho; 



import android . os . Bundle; 
import android . app .Activity; 
import android . view . Menu; 

public class MainActivity extends Activity { 

SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 

} 

@Override 

public boolean onCreateOptionsMenu (Menu menu) { 

// Aggiunge elementi all'action bar se presente. 
getMenuInf later ( ) . inf late (R. menu .main, menu); 
return true; 

} 

} 

Ricordando che uh activity è la descrizione di ima schermata dell'applicazione, notiamo come si 
tratti di una classe che estende direttamente l' omonima classe del package android . app. Vedremo nel 
dettaglio quello che è il ciclo di vita di questi componenti; per il momento osserviamo come il layout 
da noi creato e che vogliamo assegnare alla nostra schermata sia stato associato a una costante di una 
classe che si chiama r. Questa è la seconda e fondamentale proprietà delle risorse, ovvero di 
generare, per ciascuna di esse, ima costante di ima classe r che ne permetta il riferimento dall'interno 
del codice Java. In realtà per ciascuna tipologia di risorsa verrà generata un' opportuna classe statica 
interna, che nel caso del layout si chiama appunto r. layout mentre nel caso delle stringhe si chiama 
R. string. Per vedere cosa viene generato possiamo verificare il contenuto della classe r all'interno 
della cartella (Figura 2.16). 
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► E] buildConfig 
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Figura 2.16 Classe R generata automaticamente. 



Si tratta di una classe che non dobbiamo toccare e che viene generata in modo automatico in 
corrispondenza di ciascun build. Qui non abbiamo visualizzato tutte le costanti generate ma solamente 
quelle che hanno in qualche modo a che tare con quanto descritto: 

/* FILE GENERATO AUTOMATICAMENTE. NON MODIFICARE. 

* Questa classe è stata generata automaticamente 

* dall' aapt tool. Non deve essere modificata 

* manualmente . 
*/ 

package uk . co . massimocarli . android. ugho; 

public final class R { 

public static final class dimen { 

public static final int activity_horizontal_margin=0x7f 040000; 
public static final int activity_vertical_margin=0x7f 040001; 

} 

public static final class drawable { 

public static final int ic_launcher=0x7f 020000; 

} 

public static final class layout { 

public static final int activity_main=0x7f 030000; 

} 

public static final class string { 

public static final int action_settings=0x7f 050000; 
public static final int app_name=0x7f 050001; 
public static final int hello_world=0x7f 050002 ; 

} 

} 

Vedremo come l'utilizzo delle risorse sia di fondamentale importanza e come la piattaforma 
disponga di moltissimi strumenti che si aspettano come possibili valori dei propri parametri quelli 
associati alle costanti precedenti 

Nella nostra attività, nell'istruzione evidenziata, non faremo altro che associare come UI quella del 
layout identificato dalla costante r. layout .activity_main. Anche in questo caso il riferimento al 
layout è uno solo ma i layout potrebbero essere diversi, ciascuno associato a una combinazione di 
qualificatori diversa. Sarà responsabilità del dispositivo scegliere la versione più idonea alle proprie 
configurazioni e/o stato. 

Ultimo aspetto fondamentale di un'applicazione Android che affrontiamo in questa fase è quello 
relativo al file di configurazione AndroidManif est . xml. Si tratta di un documento XML che descrive 
l'applicazione al dispositivo in termini dei componenti che la stessa contiene e di come questi 
collaborino tra loro e con il sistema stesso. Nel nostro esempio quello che si chiama anche 
deployment descriptor è il seguente: 

<?xml version="l . 0" encoding="utf-8" ?> 

<manif est xmlns : android="http : / / schema s . android . com/ apk/ res /android" 
package="uk . co .massimocarli . android. ugho" 
android : versionCode=" 1 " 
android : versionName=" 1 . 0 " > 

<uses-sdk 

android :minSdkVersion=" 7 " 
android: target SdkVersion=" 16 " /> 

Opplication 

android: allowBackup="true" 

android : icon= " @drawable/ic_launcher " 
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andrò id : label= " @ string/app_name " 
android: theme="@style/AppTheme" > 
<activity 

android: name="uk . co .massimocarli . android. ugho .MainActivity" 

android: label="@string/ app_name" > 
<intent-f ilter> 

<action android: name=" android. intent . action .MAIN" /> 

<category android: name=" android. intent . category. LAUNCHER" /> 
</intent-f ilter> 

</activity> 
</application> 
</manif est> 

Notiamo che si tratta di un documento XML la cuiroot è rappresentata dall'elemento <manifest/> 
che contiene, tra gli altri, tre attributi fondamentali. Il più importante è sicuramente il package, che 
identifica in modo univoco l'applicazione e che quindi dovrà rimanere lo stesso per tutta la sua vita. Il 
versioncode è invece un valore numerico che identifica la versione dell'applicazione; è molto 
importante in fase di deploy dell'applicazione sul Play Store in quanto ogni aggiornamento dovrà, 
oltre che lo stesso package ed essere firmata conio stesso certificato, avere la versioncode 
successivo. Il versionName è invece un qualcosa che dà un nome alla particolare versione ma che non 
ha molta importanza in fase di deploy. 

Le stesse informazioni relative alle diverse versioni vengono impostate attraverso l'elemento <uses- 
sdk/>, mentre l'applicazione vera e propria è definita dall'elemento |appiication/> . In questo 
documento non ci sono tutte le possibili configurazioni, che vedremo solamente nel caso di bisogno, 
ma si può comunque osservare ancora una volta l'utilizzo che viene fatto delle risorse. In particolare, 
la risorsa identificata da @drawabie/ic_iauncher è stata utilizzata per identificare l'icona 
dell'applicazione, mentre @string/app_name è stata utilizzata per impostare il nome della stessa. 

All'interno di <appiication/> avremo la definizione dei diversi componenti tra cuiactivity, service, 
content provider e BroadcastReceiver. In questa primissima versione dell'applicazione notiamo come 
sia stata definita la nostra activity attraverso l'elemento <activity/> e di come questa sia stata 
associata a una particolare azione definita attraverso un elemento <action/>. Quello degli intent e 
degli intent filter è uno dei concetti fondamentali di Android che non vogliamo però affrontare in 
questa fase. Per il momento diciamo solamente che la nostra attività è stata associata a un evento 
relativo alla selezione dell'icona dell'applicazione nella Home del dispositivo. Questo è anche il 
significato dell'utilizzo della <category/> di nome launcher nella stessa definizione. Quando 
installeremo l'applicazione e selezioneremo la corrispondente icona nella Home del dispositivo, verrà 
generato un evento {intent) che verrà ascoltato dal sistema che manderà in esecuzione la nostra 
activity, con la conseguente visualizzazione del layout associato. 

Eseguiamo l'applicazione creata 

Il lettore troverà forse strano che sia già possibile eseguire l'applicazione creata senza alcuna 
scrittura di codice. In realtà, in fase di creazione del progetto, abbiamo preparato tutto quello che ci 
serve, ovvero un' activity dotata di layout in grado di essere lanciata dalla Home del dispositivo. 
Sebbene sia di fondamentale importanza testare le applicazioni sui dispositivi reali, l'ambiente Android 
mette a disposizione una serie di emulatori istanziabili attraverso quello che si chiama AVD (Android 
Virtual Device), che rappresenta appunto una possibile configurazione di cui un dispositivo reale può 
essere dotato. A tale proposito procediamo con la creazione di una particolare istanza di emulatore 
relativa alla versione 17 dell' API Level e dotata delle API classiche di un dispositivo certificato 
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Google. 
NOTA 

Alcuni dispositivi non sono certificati Google e quindi non dispongono di una serie di servizi che 
questa azienda mette a disposizione attraverso le proprie applicazioni. Stiamo quindi parlando di 
Play Store, delle Google Maps di Gmail e altri ancora. 

Per attivare AVD Manager selezioniamo l'icona indicata nella Figura 2.17, otterremo una finestra 
inizialmente vuota come nella Figura 2.18. 



ET: j 


A 


□ W 




AVD Manager 





Figura 2.17 Icona per l'attivazione di AVD Manager 
per la gestione dei virtual device. 
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Android Virtual Device Manager 



Android Virtual Devices 



Device Definitions 



List of existing Android Virtual Devices located at /Users/massimocarli/.android/avd 



AVD Name 



Target Name 

No AVD available 



Platform 



v A valid Android Virtual Device. A repairable Android Virtual Device. 
X An Android Virtual Device that failed to load. Click 'Details' to see the error. 



New., 



Edit... 



Delete... 



Repair.. 



Details... 
Start... 



Refresh 



Figura 2.18 AVD Manager per la creazione dei virtual device. 

Prima di procedere conia creazione di un AVD notiamo come siamo disponibili due diverse 
schede: la prima relativa ai nostri AVD e la seconda relativa a un insieme di configurazioni classiche 
presenti in un numero considerevole di dispositivi (Figura 2.19). 
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Android Virtual Device Manager 



Android Virtual Devices 



Device Definitions 




List of known device definitions. This can later be used to create Android Virtual Devices 
Device 

Nexus S by Google 
g Screen: 4.0", 480 x 800, Normal hdpi 
RAM: 343 MiB 

Nexus One by Google 
g Screen: 3.7", 480 x 800, Normal hdpi 
RAM: 512 MiB 

Nexus 7 by Google 
g Screen: 7.3", 800 x 1280, Large tvdpi 
RAM: 1024 MiB 

Nexus 4 by Google 
g Screen: 4.7", 768 x 1280, Normal xhdpi 
RAM: 1907 MiB 

Nexus 10 by Google 

O c ini" ttca w ì con v Iahm-uIu 



New Device.. 



Clone. 



Delete. 



Create AVD. 



Refresh 



3 A user-created device definition. Q A generic device definition. 



Figura 2.19 Configurazioni relative ai principali dispositivi. 

Tra le principali configurazioni notiamo quella del Nexus 4, del Nexus One, del Nexus 7 e altri 
ancora. Da quanto visto possiamo dedurre come la creazione di un AVD possa avvenire a partire da 
una configurazione completamente da definire oppure da una classica associata ai più comuni 
dispositivi Nel primo caso premeremo il pulsante New mentre nel secondo abbiamo a disposizione il 
pulsante New Device. 

Nel nostro caso selezioniamo il pulsante New ottenendo la finestra nella Figura 2.20 che abbiamo 
già riempito in alcune sue parti. 
NOTA 

Come esercizio lasciamo la seconda opzione al lettore. Le informazioni da inserire saranno 
comunque sostanzialmente le stesse ma a partire da una configurazione già preimpostata. È altresì 
bene ricordare come questa procedura non sia legata all'IDE utilizzato, il quale non fa altro che 
avviare AVD Manager, che è un tool delI'SDK di Android. 

Innanzitutto le abbiamo dato il nome MyAvd, impostando come punto dipartenza le configurazione 
di un Nexus 4. 

Notiamo come le informazioni più importanti vengano subito visualizzate, tra cui la dimensione del 
display con la relativa risoluzione classificata come xhdpi. Di seguito specifichiamo il target, ovvero 
TAPI Level supportato. 
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Create new Android Virtual Device (AVD) 



AVO Name: 

Device: 

Target: 

CPU/ABI: 
Key board 

Skin: 

Front Camera: 
Back Camera: 

Memory Options: 



MyAvd 

| Wexus4(4.r, 768 x 1280 xhdpi) 



Android 4.2.2 - API Level 17 



ARM (armeabi-v7a) 



V Hardware keyfooard present 

Display a skin with hardware controis 

Webcam O ~ 
Emulated 



RAM 1907 



VMHeap: 64 



Internai Storage: 200 



SD Card: 



• Size 1024 



File: 



MiB 



Emulation Options: VSnapshot Use Host CPU 

Override the existing AVD with the same name 



Cancel OK 



Figura 2.20 Creazione di un virtual device Android. 

Nel nostro caso abbiamo scelto il 17, ma per realizzare dei test completi dovremmo creare anche 
quelli relativi alle versioni precedenti fino alla 7 che abbiamo temporaneamente deciso di supportare. 
Dopo l'impostazione del tipo di processore, perlopiù obbligata in base al tipo di dispositivo scelto 
come riferimento, possiamo specificare se visualizzare o meno la tastiera fisica e i controlli hardware. 
Ricordiamo che non tutti i dispositivi sono dotati di questi elementi per cui, nel nostro caso, abbiamo 
scelto di non visualizzare i controlli hardware. La maggior parte dei dispositivi Android è dotata di 
videocamera anteriore e posteriore. Dalle ultime versioni del plug-in si può simulare la presenza di 
questi strumenti anche attraverso l'utilizzo della videocamera del nostro PC. Qui abbiamo deciso di 
utilizzare questa opzione solo per la videocamera anteriore mentre per quella posteriore abbiamo latto 
la scelta simulata. 

Molto importanti sono le impostazioni relative alla gestione della memoria, specialmente per quello 
che riguarda la RAM disponibile e la dimensione dell'heap (che ricordiamo essere la memoria 
utilizzata per l'istanziazione dei vari oggetti). Si tratta di una configurazione molto importante che ci 
permette di testare la nostra applicazione anche in AVD con memoria molto limitata. Specialmente se 
si gestiscono delle immagini, vedremo come questo aspetto sia critico nella gestione di 
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un'applicazione e nella prevenzione dei fastidiosi errori Out Of Memory. 

Le successive configurazioni riguardano la memoria fisica a disposizione, che viene classificata in 
interna ed esterna (SD Card). Quando vedremo la gestione dei file nel Capitolo 8, capiremo come 
accedere a queste due diverse risorse. 

L'esecuzione dell'emulatore è un'operazione spesso abbastanza onerosa che, specialmente la 
prima volta, impiegherà un po' di tempo. Per velocizzare le esecuzioni successive, l'emulatore ha 
messo a disposizione l'opzione Shapshot, che in pratica permette di rendere persistente una 
configurazione di memoria che può essere ripristinata in modo veloce all'avvio successivo. 

Infine esiste un flag che consente di abilitare o meno la Graphics Process Unit, ma si tratta di una 
configurazione utile soprattutto quando si sviluppano giochi che utilizzano gli elementi grafici in modo 
molto pesante. 

Terminato l'inserimento delle nostre configurazioni premiamo il pulsante OK ottenendo, dopo la 
comparsa di una schermata riassuntiva, la visualizzazione del nostro AVD tra quelli disponibili, come 
nella Figura 2.21. 



© O O Android Virtual Device Manager 



Android Virtual Devices 



Device Definitions 



List of existing Android Virtual Devices located at /Users/massimocarli/.android/avd 



AVD Name Target Name Platform API Level CPU /ABI 

v MyAvd Android 4.2.2 4.2.2 17 ARM (armeabi-v 



New... 



Edit... 



Delete. 



Figura 2.21 Visualizzazione degli AVD disponibili. 

A questo punto non ci resta che eseguire il nostro emulatore selezionandolo nella lista e quindi 
premendo il pulsante Start, il quale porta alla finestra nella Figura 2.22. Oltre alla visualizzazione delle 
informazioni relative al display dell' AVD, ci viene data la possibilità di eseguire un resize in base a 
quelle che sono le dimensioni del nostro schermo. Lasciando le impostazioni di default capita infatti 
spesso che l'emulatore assuma dimensioni esageratamente grandi Per questo motivo abbiamo 
modificato tali valori impostando 8 come dimensioni in pollici (in) dello schermo. Sarà cura del lettore 
verificare il valore compatibile con le dimensioni e la risoluzione del proprio PC di sviluppo. 

L'opzione Wipe user data permette la cancellazione di tutti i dati del dispositivo in modo da 
simularne un reset. Possiamo poi decidere di avviare l'emulatore a partire dallo snapshot abilitato in 
precedenza e infine salvare lo stesso al termine dell'esecuzione dell' AVD. Finalmente possiamo 
selezionare il pulsante Launch e avviare il nostro emulatore, che apparirà come nella Figura 2.23, 
mostrando la classica schermata dihelp caratteristica del primo avvio. 
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^> Launch Options 



Skin: 768x1280 

Density: 320 

[V^ Scale display to real size 



Screen Size (in): 

Monitor dpi: 
Scale: 



8 



72 



0,39 



(j Wipe user data 

(vj Launch from snapshot 

iv^Save to snapshot 



Cancel 



Launch 



Figura 2.22 Opzioni di avvio dell'emulatore. 
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5554:MyAvd 



*j i 12 53 



Make yourself at home 

You can put your favorite apps here 





To see ali your apps. touch the circle 



■(©)5 




Figura 2.23 Primo avvio dell'AVD. 

Come detto, vogliamo però eseguire la nostra applicazione, cosa ancora non immediata, che 
necessita della creazione di un' opportuna configurazione che si imposta selezionando l'opzione nella 
Figura 2.24 (nella barra degli strumenti in alto nel nostro IDE). 



01 


■ * ■ M 1 1 


CI & ÉT: : 


■ W j 

! È 


[/ Edit Configurations... 




build.gradle x <> activitv 



Figura 2.24 Creazione di una configurazione per l'esecuzione dell'applicazione nell'AVD. 

Selezionando questa opzione il nostro editor aprirà un wizard per la creazione di diverse 
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configurazioni. Selezionando il pulsante + nella parte in alto a sinistra possiamo creare diverse 
tipologie di configurazioni, tra cui sceglieremo quella di nome Android Application. Come mostrato 
nella figura, possiamo assegnare un nome e selezionare il corrispondente modulo attraverso un menu a 
tendina. Ci viene poi consentito di scegliere se lanciare o meno Fattività principale come definito in 
AndroidManif est . xml e quindi di eseguire il deploy (installazione) dell'applicazione. La sezione 
successiva riguarda il dispositivo o AVD che dovrà eseguire l'applicazione. Nel caso di più possibilità 
si potrà richiedere la visualizzazione di un chooser, ovvero di una lista tra cui scegliere, e dare la 
priorità al dispositivo connesso via USB oppure a un particolare AVD come latto nel nostro caso. 
Attraverso un menu a tendina abbiamo infatti selezionato l' AVD creato in precedenza e di nome 
MyAvd. 



Run/Debug Confìgurations 



▼ ■ Android Application 

UCHO 
► Defaults 



? 



Name: UCHO 



Module: UGHO-UGHO %\ 

Do not launch Activity 
@ Launch default Activity 

Launch: 
J Deploy application 
Target Device 

Show chooser dialog 
USB device 
• Emulator 
Prefer Android Virtual Device: 



- Before launch: Make 
I Make 



Share 



Emulator Logcat 



MyAvd 



E 



Show this page 



Cancel Apply OK 



Figura 2.25 Creazione di una configurazione per l'esecuzione dell'applicazione. 

Prima di premere il pulsante OK diamo m'occhiata veloce alle altre due schede di nome Emulator 
e Logcat. La prima è molto utile nel caso si volessero emulare dispositivi con una particolare tipologia 
di connessione (3G, GPRS, UMTS e così via) e diversi gradi di latenza. Infine, il Logcat è mio 
strumento di fondamentale importanza per la visualizzazione del log del dispositivo, che possiamo 
decidere di cancellare completamente a ogni avvio. 

Selezionando il pulsante OK notiamo come sia stata creata una configurazione visualizzata come 
opzione nel menu a tendina che precedentemente era vuoto, e che ora contiene quello nella Figura 
2.26. 
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*fi |#UGHO^ ► 


* ci 1? 





Figura 2.26 Pulsante per l'avvio dell'applicazione con la configurazione di nome UGHO. 

Selezionando il pulsante Play otteniamo l'esecuzione della nostra applicazione nell'emulatore e 
quindi la visualizzazione di quello nella Figura 2.27. Notiamo come il layout sia stato visualizzato 
all'interno della schermata associata alla nostra activity descritta dalla classe MainActivity. 



5554:MyAvd 



i é no 



UGHO 



Hello world 1 




Figura 2.27 Esecuzione dell'applicazione nell'AVD creato. 

Dopo tanta làtica e moltissimi concetti siamo arrivati alla creazione ed esecuzione di 
un' applicazione Android senza scrivere alcuna riga di codice. E importante ricordare al lettore di non 
spaventarsi, in quanto riprenderemo tutti i concetti qui solo accennati Purtroppo la piattaforma 
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necessita di uno sforzo iniziale non indifferente che speriamo di semplificare nei capitoli successivi. 

Installazione di ambienti e librerie 

Nella parte iniziale del capitolo abbiamo parlato di quanto sia importante il concetto diAPI Level e 
diversione dell'ambiente Andro id. Abbiamo quindi creato un progetto che promette di supportare 
tutte le versioni dalla 7 alla 17, a ciascuna delle quali corrisponde un ambiente di runtime, delle classi, 
dei tool e degli strumenti che possiamo gestire attraverso un tool che si chiama SDK Manager e che 
si apre selezionando il pulsante nella Figura 2.28. 



siuaiorrojecis/utjHuj - 


a 




i ? 

• 




SDK Manager 







Figura 2.28 Avvio di SDK Manager. 



Si tratta sostanzialmente di un tool per i download delle diverse versioni dell' SDK, oltre che di 
particolari librerie di supporto come quella di compatibilità o per la gestione dei servizi di Google 
Play, come vedremo nei capitoli successivi 

Selezionando le librerie da installare si potrà procedere al relativo download selezionando il 
pulsante Instali. Nel nostro caso scarichiamo i file mancanti relativi alla versione 4.2.2 della 
piattaforma, che corrisponde all' API Level 17. Tra questo notiamo appunto le Google API a cui 
avevamo accennato in precedenza. Non tutte queste componenti sono disponibili per tutte le 
piattaforme di sviluppo. Per esempio, i driver USB non sono disponibili in ambiente Mac OS ma 
solamente in ambiente Windows. Analogamente a quanto fatto per le versioni dell' SDK, possiamo 
scaricare alcune librerie di supporto come evidenziato nella Figura 2.30. Consigliamo al lettore di 
scaricare le librerie indicate di cui descriveremo in modo approfondito le principali 

Alcune di queste sono state unificate come annunciato all'ultima Google IO del 2013. Per esempio, 
le API relative alla gestione della location e quelle relative al GCM {Google Cloud Messaging) sono 
state inserite all'interno dei Google Play Services. Avremo comunque modo divedere queste API 
nei prossimi capitoli. 

Conclusioni 

Siamo quindi giunti alla fine di questo primo capitolo, che si è rivelato molto impegnativo a causa 
dei numerosi concetti accennati e che saranno argomento dei prossimi capitoli a partire dalla gestione 
delle activity. Abbiamo iniziato con l'installazione del nuovo IDE che si chiama Andro id Studio e che è 
basato su IntelliJ. Abbiamo quindi creato il nostro primo progetto seguendo le impostazioni standard e 
descritto nel dettaglio la struttura delle directory ottenuta. Abbiamo descritto i componenti più 
importanti della maggior parte delle applicazioni Andro id ovvero le activity, i layout e il file 
AndroidManif est . xml di configurazione. Siamo così pronti ad affrontare, nel capitolo successivo, il 
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nostro progetto UGHO, iniziando dalla struttura delle schermate. 
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Android SDK Manager 



SDK Parti: /Appllcations/Androld Studio. app/sdk 
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Figura 2.29 Android SDK Manager per il download degli ambienti. 
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Figura 2.30 Le librerie disponibili per il download. 
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Capitolo 3 



Le activity e il flusso di navigazione 



Nel Capitolo 2 ci siamo preparati alla realizzazione del nostro progetto che si chiama UGHO 
{User Generateci Horoscope) attraverso l'utilizzo del nuovo toolAndroid Studio, presentato come la 
nuova alternativa a eclipse all'ultima Google IO del 2013. A dire il vero nel capitolo precedente non 
abbiamo scritto alcuna riga di codice ma abbiamo semplicemente creato il progetto seguendo le 
configurazioni di delàult e poi visto come sia possibile eseguirlo attraverso un Android Virtual 
Device. In questo capitolo vogliamo quindi creare il nostro progetto iniziando da quella che sarà la 
struttura delle schermate che, come già accennato, saranno descritte da altrettante activity di cui 
esamineremo il ciclo di vita. Approfitteremo di questa tàse anche per la descrizione di alcune delle 
principali tipologie di risorse. Alcune delle funzionalità della nostra applicazione non saranno 
disponibili prima di aver esaminato strumenti che descriveremo nei capitoli successivi Per questo 
motivo realizzeremo delle classi (che possiamo definire modi) con dati cablati al loro intemo 
simulando in qualche modo l'interazione con eventuali sistemi esterni o con i meccanismi di gestione 
della persistenza. 

Il progetto UGHO 

L'approccio che ho voluto dare a questa versione della guida è molto pratico e prevede la 
realizzazione di un'applicazione vera e propria. Si tratterà di un'applicazione che modificheremo e 
amplieremo di volta in volta aggiungendo nuove funzionalità o realizzando quelle disponibili in modo 
diverso utilizzando specifiche API della piattaforma Android. Per esempio, inizialmente utilizzeremo un 
meccanismo di autenticazione molto semplice che poi verrà sostituito dalla gestione degli account di 
Android. Lo stesso per quello che riguarda l'interazione con un server, che inizialmente verrà simulato 
da un semplice oggetto e che successivamente dovrà utilizzare degli strumenti che ci permetteranno di 
accedere alla rete in modo asincrono. Anche quella che possiamo considerare la base dati cambierà 
nel corso dello sviluppo come è comunque abbastanza comune fare a seguito di modifiche delle 
specifiche da parte di un cliente; si tratta di una delle caratteristiche principali dei metodi agili Ma 
cosa dovrà fare questo UGHO? Sarà capitato a tutti di sfogliare un quotidiano e di leggere il proprio 
oroscopo sia nel caso in cui ci si creda o che si pensi siano tutte invenzioni. La nostra applicazione 
non permetterà la semplice visualizzazione del proprio oroscopo scritto da un qualche astrologo 
famoso o meno, ma seguirà un percorso completamente inverso. Saranno gli utenti che descriveranno 
il proprio stato d'animo relativo ai classici argomenti lavoro, amore, salute e fortuna. L'applicazione 
raccoglierà queste informazioni inviandole a un server fornirà delle statistiche che ci diranno se questi 
stati d'animo sono legati o meno alla data di nascita e quindi al segno zodiacale. Qui non ci 
addentreremo in calcoli troppo complicati come per esempio quello dell'ascendente, ma ci 
concentreremo solamente sugli aspetti legati alla programmazione Android. 

NOTA 

Questo permette a chi crede nell'oroscopo di avere una giustificazione nel caso in cui i dati non 
dipendano dal segno zodiacale. Il lettore potrà comunque estendere il presente codice per 
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aggiungere funzionalità di questo tipo. 

L'albero di navigazione che intendiamo sviluppare in questo capitolo è quello descritto nella Figura 
3.1. Quello che abbiamo voluto mettere in evidenza in questo diagramma non è l'aspetto grafico ma 
solamente quello funzionale. 

NOTA 

Quando tratteremo le risorse di tipo style vedremo come rendere l'interfaccia accattivante. Per il 
momento ci accontentiamo di creare qualcosa che funziona, almeno per quello che riguarda la 
navigazione e la successione delle schermate. 

Quando l'applicazione viene avviata si ha la visualizzazione di una schermata di splash, ovvero 
un'immagine che dovrebbe rimanere sul display per un tempo fissato oppure apparire quando l'utente 
preme un particolare pulsante o semplicemente tocca lo schermo. La nostra prima activity sarà infatti 
quella che visualizzerà un'immagine per poi andare alla schermata successiva in corrispondenza del 
trascorrere di un tempo definito oppure al tocco del display. Come vedremo si tratterà di un' activity 
non banale, in quanto nasconderà alcuni concetti molto importanti di multithreading che vedremo nel 
Capitolo 9, ma che cercheremo comunque di anticipare per quanto possibile. 

A questo punto dobbiamo affrontare un problema molto importante: la nostra applicazione 
potrebbe prevedere la registrazione da parte dell'utente oppure l'accesso anonimo. Nel primo caso 
dobbiamo implementare una logica di registrazione e di login. Nel secondo caso dovremo comunque 
richiedere all'utente almeno rinformazione relativa alla sua data di nascita per poter calcolare il suo 
segno zodiacale. 




■ SiilE 




Figura 3.1 Successione delle schermate della prima versione di UGHO. 



Si tratta di informazioni che dovremo poi memorizzare, specialmente nel caso non anonimo, da 
qualche parte, in modo da non obbligare l'utente a ripetere le stesse operazioni a ogni esecuzione 
dell'applicazione. Anche in questo caso anticiperemo qualcosa relativamente all'utilizzo di un oggetto 
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per la gestione delle preferenze implementando un pattern abbastanza comune nello sviluppo di 
Android. 

Nel caso della registrazione creeremo ima schermata per l'inserimento delle informazioni. Nel caso 
del logjn realizzeremo un'interfaccia per l'inserimento delle credenziali. In questo caso avremo 
l'occasione di descrivere una modalità alternativa di interazione tra le activity che è diversa dal 
normale passaggio da una schermata alla successiva; la prima attività utilizzerà infatti quella di login 
per raccogliere delle informazioni che la stessa poi utilizzerà per prendere alcune decisioni 

NOTA 

Un caso analogo è quello di una schermata che permette la selezione di un'immagine presente 
nella gallery o di un contatto nella proprio rubrica. Potremmo considerare tale schermata come di 
supporto. 

Al termine di questa fase di riconoscimento (o meno) dell'utente, si arriverà a una schermata con 
tre diverse opzioni che permetteranno all'utente di inserire nuove informazioni, accedere al proprio 
storico oppure alle statistiche remote ottenute attraverso l'accesso al server. L'aggiunta di nuove 
informazioni corrisponderà poi all'inserimento dello stato d'animo relativo ad amore, salute, lavoro e 
fortuna. In questa fase le schermate conterranno perlopiù delle etichette descrittive che andremo poi a 
sostituire mano a mano con i componenti grafici corretti 

La schermata di splash, risorse Drawable e 

intent espliciti 

Iniziamo lo sviluppo della nostra applicazione dalla prima attività che verrà visualizzata al momento 
di avvio dell'applicazione e che ha il compito di mostrare un'immagine per un tempo definito oppure 
fino a quando l'utente non tocca il display. Come accennato, si tratta di un componente meno 
semplice di quello che sembra in quanto necessita della conoscenza di concetti non banali che sono 
comunque di fondamentale importanza nello sviluppo di applicazioniAndroid, che incontreremo 
spesso anche nei capitoli successivi e che quindi esamineremo qui nel dettaglio. Stiamo parlando di: 

• risorse di tipo Drawable; 

• intent espliciti; 

• utilizzo di un handler. 

Le risorse di tipo Drawable caratterizzano tutto ciò che può essere visualizzato, tra cui anche le 
immagini Gli intent rappresentano il meccanismo che sta alla base di tutta rarchitettura Android e che 
permette ai diversi componenti di comunicare tra di loro. Un handler è invece un meccanismo che ci 
consente di interagire con il thread responsabile della gestione della UI. Mettiamoci al lavoro. 

Le risorse 

Come accennato in precedenza, le risorse rappresentano una parte fondamentale di ciascun 
progetto Android e sono descritte da opportuni file contenuti in directory predefinite all'interno della 
cartella /src/main/res del progetto ugho. Sebbene gran parte delle risorse possa essere definita 
attraverso righe di codice Java, Android favorisce l'approccio dichiarativo in quanto di più semplice 
gestione, specialmente alla luce della possibilità di selezionare la particolare versione di una risorsa in 
modo automatico attraverso l'uso di opportuni qualificatori Per capirne il funzionamento osserviamo 
la Figura 3.2 relativamente alle risorse di tipo Drawable. 
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Figura 3.2 Struttura a directory delle risorse di tipo Drawable. 

Come possiamo notare sono state create quattro diverse cartelle che iniziano per drawable e che 
sono seguite da un codice detto qualificatore. In questo caso si tratta di una stringa che identifica una 
particolare risoluzione del display che andrà a visualizzare la risorsa stessa. Vediamo poi come in ogni 
cartella vi sia un'immagine, relativa alla nostra icona, rappresentata da un file con lo stesso nome. È 
importante sottolineare, come approfondiremo più avanti, come la risorsa per la piattaforma sia una 
sola ovvero quella associata alla costante r . drawable . ic_iauncher generata automaticamente in tàse 
di building, che potremmo utilizzare nel nostro codice Java, o alla stringa @ drawable /i c_launcher che 
potremmo invece utilizzare all'interno di altri file che descrivono le risorse. Osservando, per esempio, 
il file di configurazione AndroidManif est . xml abbiamo infatti la seguente definizione: 

Opplication 

android: allowBackup="true" 

android : icon= " gdrawable/ ic_launcher " 

android: label="@string/ app_name " 
android : theme="@style/AppTheme" > 

</application> 

Sarà poi il particolare dispositivo che andrà a prendere la versione dell'immagine corrispondente 
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alla risoluzione del proprio display. Il lettore potrà verificare come si tratti di file corrispondenti a 
immagini che differiscono effettivamente per la densità delle informazioni Per esempio il file 
ìc_launcher .png relativo all'icona per display ad alta densità (HDPI, High Density Per Inch) ha 
dimensioni 72x72 pixel e un peso di 2827 byte, mentre l'equivalente per densità media (mdpi) ha 
dimensioni 48x48 pixel e un peso di 1898 byte, e quindi inferiore. 
NOTA 

Le dimensioni e il peso esatti dipenderanno dalle icone generate in fase di creazione del progetto. 

Come sappiamo ogni giorno vengono messi sul mercato moltissimi nuovi dispositivi Andro id, 
ciascuno dei quali con caratteristiche hardware diverse che vengono classificate in alcune categorie. 
Per quello che riguarda la densità del display, abbiamo le categorie corrispondenti alle altrettante 
cartelle e quindi bassa (Ihdp), media (mdpi), alta (hdpi) e altissima (xhdpi) densità. Se il dispositivo 
che sta eseguendo la nostra applicazione ha una densità del display classificata come media, ciascun 
riferimento a ic_launcher Sarà relativo alla risorsa h/res/drawable-mdpi/ic_launcher.png. Se il 
dispositivo ha una densità altissima (come un tablet) la stessa risorsa (che sappiamo essere comunque 
associata a una costante r. drawabie . ic_iauncher) tàrà riferimento al file con lo stesso nome ma nella 
cartella /re s/drawable -xhdpi. È bene sottolineare come non esista una relazione tra le diverse cartelle: 
nel caso di mancata risorsa nella cartella associata ai display ad alta risoluzione, un dispositivo 
classificato come tale non andrà a prendere la versione relativa alla densità media ma cercherà nella 
corrispondente cartella di default, che è quella che non fà riferimento al qualificatore e che nel nostro 
caso sarebbe /res/drawable. 

NOTA 

In realtà questo è il comportamento predefinito di tutte le risorse, che vedremo poter essere 
leggermente diverso nel caso delle Drawable attraverso l'utilizzo di opportuni attributi che ci aiutano 
leggermente nel caso in cui tali risorse mancassero per una particolare risoluzione. Vedremo il tutto 
nel Capitolo 4, quando specializzeremo la nostra applicazione anche per i tablet. 

Questo ci porta a dire che è sempre bene fornire, per ciascuna risorsa, delle informazioni di default 
che saranno poi quelle selezionate nel caso in cui il dispositivo non abbia caratteristiche o 
configurazioni corrispondenti al qualificatore utilizzato. Per ogni tipo di risorsa si possono utilizzare più 
qualificatori relativi ad aspetti diversi della piattaforma. Potremmo quindi, teoricamente, creare una 
risorsa di tipo Drawable da utilizzare nel caso di dispositivi ad alta densità (hdpi), quando sono in 
modalità landscape e in lingua italiana creando una cartella di nome /res/drawable-it-land-hdpì. E 
importante comunque che, quando specificati, i qualificatori seguano un ordine prestabilito, che è 
quello relativo alla tabella che è possibile consultare nel dettaglio all'indirizzo 

http : // developer . android . com/guide/topics/ resources/providing-resources . html e che 

ripetiamo nella Tabella 3.1 per convenienza. 

Più importante è sicuramente la descrizione di quella che è la regola di selezione di una risorsa in 
base alle caratteristiche o impostazioni del dispositivo. Come detto, l'ordine dei qualificatori è 
fondamentale. Quando il dispositivo ha la necessità di utilizzare una particolare risorsa inizia la ricerca 
partendo dal primo qualificatore della lista, ovvero quello associato a MCC e MNC per poi 
proseguire con i successivi. Una risorsa verrà scartata se definisce un valore esplicito per un 
qualificatore che è in contrasto con quello del dispositivo. Per descrivere meglio questo procedimento 
ci aiutiamo con un esempio relativo alle risorse di tipo Drawable. Supponiamo che la nostra 
applicazione disponga delle risorse corrispondenti alle seguenti cartelle: 

/ drawable 

/ drawable-it-land 

/ drawable-en-large-port 
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/ drawable-port-v4 
/ drawable-land-v7 

Come detto il processo di ricerca della nostra risorsa parte dal primo qualificatore, ovvero MCC 
ed MNC, per i quali non esiste alcuna definizione esplicita. Nessuna delle cartelle verrà quindi esclusa 
e si passa al qualificatore successivo, cioè quello relativo alla lingua che supponiamo essere quella 
italiana e quindi identificata dal valore it. Tra quelle definite dovremo quindi scartare tutte quelle 
risorse che hanno definito in modo esplicito una lingua diversa. In questo caso la cartella scartata sarà 
la seguente: 

/drawable-en-large-port 

Le cartelle che conterranno la risorsa candidata rimangono quindi le seguenti; 

/ drawable 

/ drawable-it-land 

/drawable-port-v4 

/ drawable -land-v7 

Notiamo come le cartelle che non esplicitano una lingua siano comunque mantenute. Proseguendo 
con l'elenco dei qualificatori, il successivo indicato in modo esplicito è quello relativo all'orientamento 
del display, che è esplicitato in tre delle cartelle, ovvero 

/ drawable-it-land 
/drawable-port-v4 
/drawable-land-v7 



Tabella 3.1 Elenco di qualificatori in ordine di priorità. 





Descrizione 


MCC e MNC 


Mobile Country Code e Mobile Network Code rappresentano un modo per identificare 
in modo univoco un particolare operatore telefonico. Insieme definiscono quello che si 
chiama International Mobile Subscriber Identity (IMSI). 


Lingua e 
regione 


Come visto in precedenza è possibile utilizzare dei qualificatori relativi alla lingua e 
alla regione impostate nel dispositivo. 


smallestWidth 


Attraverso questo qualificatore è possibile specificare i dispositivi attraverso quella 
che è la loro dimensione minore. 


availableWidth 
availableHeight 


Si tratta di due qualificatori simili al precedente ma che fanno riferimento allo stato 
corrente del dispositivo. 


Dimensioni 
schermo 


Oltre che per la densità, i display dei vari dispositivi si differenziano soprattutto per le 
dimensioni, che sono state classificate in base ad alcuni valori presi come 
riferimento, per i quali rimandiamo alla documentazione ufficiale. Nel nostro caso è 
importante sottolineare come i qualificatori possano essere smaii, nomai, iar ge e xiar ge . 


Tipo schermo 


Un'altra caratteristica del dispositivo che non dipende dall'orientamento è quella 
relativa al rapporto delle dimensioni del display, che può essere definita come io ng o 

notlong. 


Orientamento 
schermo 


Nel caso in cui volessimo qualificare alcune risorse in base all'orientamento del 
dispositivo, i possibili valori da utilizzare sarebbero por t (portraif) e land (landscape). 
Come vedremo si utilizzano principalmente per la specializzazione dei layout. 


Modalità Ul 


Questo qualificatore può assumere i valori C ar, desk, teievision e a PP iìance e ci permette 
di specificare le risorse in base alla modalità con cui la nostra applicazione viene 
utilizzata. 


Modalità notte 


In questo caso i valori sono night e notnight e permettono di classificare le risorse in 
base all'ora del giorno in cui vengono utilizzate. 


Densità del 
display 


Come abbiamo accennato in precedenza, i dispositivi vengono classificati in base a 
quella che è la densità dei display a disposizione. 1 principali valori da utilizzare come 
qualificatori sono i seguenti: id P i, md P i, hd P i e xhd P i 


Tipo di touch 


Attraverso il qualificatore notouch è possibile specializzare alcune risorse per i 
dispositivi che non sono dotati di un touchscreen. L'alternativa è descritta dal 
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qualificatore finger. 


Disp. tastiera 


1 primi dispositivi Android avevano una tastiera fisica che poteva essere chiusa 
attraverso un meccanismo a scivolamento. Ora la maggior parte dei device dispone di 
una tastiera virtuale. In ogni caso i qualificatori che ci permettono di specializzare le 
risorse in tal senso sono i seguenti: keysexposed, keysnìddene keysoft. 


Tipo di input 
primario 


Indipendentemente dalla disponibilità o meno della tastiera fisica, un aspetto 
importante dei dispositivi è quello relativo alla modalità di inserimento del testo. Si 
tratta di un aspetto fondamentale soprattutto dal punto di vista dell'usabilità. In tal 
senso è possibile utilizzare i seguenti qualificatori: nokeys, querty e i2k ey . 


Disponibilità 
tasti di 
selezione 


Un discorso analogo si può fare per i tasti che permettono la selezione dei diversi 
componenti in un'interfaccia grafica. Nel caso in cui si tratti di strumenti visibili si 
utilizza il qualificatore navexposed, per usare poi il valore navhidden in caso contrario. 


Metodi 

navigazione 

alternativi 


Relativamente al qualificatore precedente è possibile specificare di cosa si tratta 
ovvero se si dispone del normale touchscreen (nonav), di un directional pad (d- P ad), di 
una trackball (tracimali) o della classica "rotella" (wheei). 


API Level 


Alcune risorse possono essere qualificate in base alla versione della piattaforma. 
Vedremo come questo qualificatore sia importante nella gestione degli stili in quanto 
disponibili solamente da alcune versioni in poi. 



Supponiamo che il nostro dispositivo sia nello stato portrait (o verticale) caratterizzato dal 
qualificatore port. Questo ci permette di scartare le seguenti due cartelle, che definiscono in modo 
esplicito un orientamento diverso, che in questo caso è quello associato al valore land corrispondente 
alla posizione landscape (che per semplificare possiamo pensare come orizzontale): 

/ drawable-it-land 
/ drawable-land-v7 

Le uniche cartelle rimaste sono quindi le seguenti; 

/ drawable 
/drawable-port-v4 

A questo punto l'ultimo qualificatore esplicito è quello relativo all' API Level. Le risorse nella 
cartella /drawable-port-v4 verranno selezionate solamente nel caso in cui il dispositivo sia dotato di 
un API Level maggiore o uguale al 4. Negli altri casi la risorsa verrebbe scelta tra quelle nella cartella 
/drawable, che viene detta di default in quanto conterrà tutte le risorse relative alle configurazioni non 
previste in modo esplicito. Dotare ciascuna tipologia di risorse di una versione didefault (ovvero priva 
di qualificatori) è cosa auspicabile non solo per gestire comunque tutti i dispositivi ma anche per non 
incorrere in errori nel caso in cui nuovi qualificatori venissero aggiunti nelle versioni successive della 
piattaforma. 

Per fare un esempio concreto consideriamo i qualificatori relativi ai layout che ci porterebbero alla 
definizione delle seguenti cartelle: 

/layout-port 
/layout-land 

Questo perché al momento i qualificatori sono due e precisamente quello relativo alla posizione 
portrait (port) e quello relativo alla posizione landscape (land). Nel caso in cui venisse introdotto un 
nuovo qualificatore, che chiamiamo newquai, una posizione del dispositivo classificata come tale non 
troverebbe alcuna risorsa di layout disponibile. La regola descritta prevede infatti che vengano 
scartate tutte le cartelle che specificano un valore esplicito del qualificatore diverso da quello 
supportato. La soluzione consiste semplicemente nel definire uno di questi qualificatori come quello di 
default e associare le relative risorse alla corrispondente cartella. Nel nostro esempio la soluzione 
consiste nel definire le seguenti directory 

/layout 
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/layout-land 

dove la posizione portrait è quella promossa a default. In questo caso la posizione associata al 
nuovo qualificatore verrebbe comunque coperta dalle risorse di detàult, in quanto non esplicitante 
alcun qualificatore. 

Un'altra fondamentale caratteristica di tutte le risorse è quella di poter essere referenziate 
attraverso un'apposita costante di una classe r generata automaticamente in fase di building oppure 
da un'opportuna sintassi da utilizzare all'interno di documenti XML di altre risorse. Vedremo in vari 
casi come tutta la piattaforma ci permetta di utilizzare tali costanti in diversi contesti Se torniamo al 
codice della nostra activity nel capitolo precedente notiamo infatti come la costante 
r. layout . activity_main sia stata utilizzata per l'impostazione del layout attraverso la seguente 
istruzione: 

setContentView (R. layout . activity_main) ; 

A ogni risorsa è poi associato un identificatore che segue la sintassi 

@ [package :] <tipo risorsa>/<nome risorsa> 

il quale ci permette di referenziarla a partire da altre risorse. Un caso tipico è quello relativo al 
documento AndroidManifest .xml in cui abbiamo evidenziato l'utilizzo di 

android: icon=" @drawable/ic_launcher " 
android: label=" @string/app_name" 

per fare riferimento rispettivamente all'immagine da utilizzare come icona dell'applicazione e il 
corrispondente nome: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<manif est xmlns : android="http : //schemas . android . com/ apk/ re s /android" 
package="uk . co .massimocarli . android. ugno" 
android : versionCode=" 1 " 
android : versionName=" 1 . 0 " > 

<uses-sdk 

android: minSdkVersion=" 7 " 
android: target Sdk Versi on=" 16 " /> 

<application 

android: allowBackup="true" 
android:icon="@ dr awabl e / i c_launche r " 
android : label= " @ string/ app_name " 

android: theme="@ sty le/ AppTheme " > 
<activity 

android: name="uk . co . massimocarli . android . ugho . MaìnActivìty " 
android: label="@string/app_name" > 
<intent-f ilter> 

<action android: name="android. ìntent . action . MAIN" /> 

<category android: name="android. intent . category . LAUNCHER" /> 
</intent-filter> 
</activity> 
</application> 

</manif est> 

Quando ci occuperemo dei layout, ovvero delle risorse forse più importanti, vedremo come sia 
possibile associare ai diversi componenti grafici delle risorse del tipo 

@+id/<nome rìsorsa> 

che quindi ci permetteranno di referenziarle da codice Java attraverso l'uso delle costanti 

R.id.<nome rìsorsa> 

Avremo modo di vedere nel dettaglio tutti i vati tipi di risorse; per il momento ci concentriamo sulla 
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risorsa che vogliamo utilizzare come sfondo della nostra splash e che supponiamo essere 
rappresentata dal file di nome spiash_image.png. Qui scegliamo come immagine di sfondo della 
nostra splash l'unica immagine che abbiamo a disposizione, ovvero l'icona. Come abbiamo imparato 
in precedenza, il primo passo consiste nel promuovere una delle risoluzioni a quella di default. Nel 
nostro caso prendiamo come risoluzione di default quella hdpi. Per farlo ci basterà rhorninare la 
cartella drawable-hdpi ìa drawable attraverso la funzione di refactoring del nostro tool. Selezioniamo 
quindi la cartella drawable-hdpi con il tasto destro del mouse e selezioniamo l'opzione Renarne del 
menu Refactor come nella Figura 3.3. Otterremo la finestra nella Figura 3.4, dove inseriamo il nuovo 
nome della cartella che diventa quindi quella di default per le risorse di tipo Drawable. 
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Figura 3.3 Funzione di refactoring. 
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Figura 3.4 Refactoring della cartella dei drawable. 

Un'alternativa poteva essere quella di aggiungere semplicemente la cartella drawable copiando le 
risorse della cartella associata alla risoluzione hdpi. 

In futuro cambieremo l'immagine associata alla nostra splash per cui copiamo per ciascuna delle 
risoluzioni l'icona dandogli il nome splash_image.png indicato precedentemente. A questo punto 
ciascuna delle cartelle conterrà due immagini, e la nuova costante r. drawable . spiash_image verrà 
creata automaticamente. 
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Creazione del layout 

Una volta disponibile l'immagine (provvisoria) da utilizzare ci accingiamo alla realizzazione del 
layout, che sarà molto semplice. In questa fase abbiamo due possibilità. La prima consiste 
nell'utilizzare l'immagine come sfondo (background) dell'intero layout. La seconda consiste 
nell'utilizzare un componente che si chiama imageview e che permette appunto di visualizzare delle 
immagini La scelta dipende da molti fattori ma soprattutto dalle regole di resizing a seguito della 
variazione delle dimensioni del display a causa, per esempio, di una rotazione. Per capire la differenza 
creiamo il layout con la prima opzione. Selezioniamo con il tasto destro del mouse la cartella layout 
nelle risorse e poi scegliamo l'opzione New > Layout resource file come nella Figura 3.5. 
Ricordiamo infatti che anche i layout sono delle vere e proprie risorse. 
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Figura 3.5 Creazione di una nuova risorsa di layout. 



Si ottiene quindi la visualizzazione della finestra nella Figura 3.6, nella quale viene chiesto il nome 
del file di layout e l'elemento di root. Questa seconda opzione permette di decidere quale dovrà 
essere l'elemento contenitore degli elementi descritti dal layout stesso. Inizialmente viene proposto il 
layout descritto dalla classe LinearLayout, che permette di disporre il proprio contenuto secondo un 
ordine orizzontale o verticale. Nel nostro caso scegliamo invece il layout descritto dalla classe 
FrameLayout, che consente di posizionare ciascun elemento al proprio intemo in modo indipendente 
dagli altri dando loro solamente un ordine lungo l'asse z (per intenderci, i primi componenti staranno 
sotto quelli che li seguono). 



© O O New Layout Resource File 






File name: 


activity_splash 






Root element: 

, — ■ 


| Fram| | 


FrameLayout 
NoSaveStateFrameLayout 





Figura 3.6 Creazione di un layout. 
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NOTA 

Come vedremo nel Capitolo 5, i layout definiscono la modalità con cui i diversi componenti vengono 
disposti all'interno del display specificandone anche le dimensioni. 

Selezionando il pulsante OK si avrà quindi la creazione del layout, che inizialmente conterrà 
appunto solamente la definizione delFrameLayout sarà caratterizzato dal seguente documento XML: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 

android : layout_width="match_jparent " 

android : layout_height="match_parent "> 
</FrameLayout> 

Come detto la prima opzione che vogliamo verificare per lo sfondo consiste nelT utilizzare la nostra 
immagine come background e questo è possibile attraverso l'attributo evidenziato nel seguente 
codice: 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 
android : layout_width="match_jparent " 
android : layout_height="match_parent " 
android : background= " @drawable/splash_image " > 

</FrameLayout> 

Il risultato si può vedere nella preview nella parte destra del nostro IDE. Nel caso in evi volessimo 
verificare il risultato su più tipologie di display abbiamo anche visto come abilitare la corrispondente 
opzione {Preview Ali Screen Sizes), ottenendo quanto mostrato nella Figura 3.7. 




Figura 3.7 Preview della splash su display diversi. 



Adire il vero il risultato non è ottimale, soprattutto suunNexus 10 in posizione landscape. La 
nostra immagine viene utilizzata come background e quindi viene ridimensionata a seconda di quello 
che è lo spazio disponibile. Questo è il significato degli attributi evidenziati nel codice: 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 
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android : layout_width= "match_parent " 
android : layout_height="match__parent " 

android : background= " @drawable/ splash_image"> 
</FrameLayout> 

Ci dicono sostanzialmente che il layout si deve adattare a quello che è lo spazio nel display e quindi 
occuparlo completamente. Il secondo problema del layout precedente consiste nella presenza 
dell'action bar, ovvero di quella barra nella parte superiore del display contenente l'icona e il titolo 
dell'applicazione. Risolviamo subito questo problema attraverso l'utilizzo di quello che si chiama tema 
e che sostanzialmente ha la stessa lùnzionalità di un CSS in una pagina HTML. I temi ci permettono di 
specificare, in modo dichiarativo, alcune caratteristiche relative a tutti i componenti grafici In questo 
caso possiamo indicare il fullscreen attraverso la seguente impostazione nel file AndroidManif est . xml'. 
<activity 

android: theme="@ android: style/Theme .NoTitleBar .Fullscreen" 

android: name="uk . co . massimocarli . android . ugno .MainActivity " 

android: label="@string/ app_name" > 

<intent-f ilter> 

<action android: name=" android. intent . action . MAIN" /> 
<category android: name="android. intent . category . LAUNCHER" /> 

</intent-filter> 
</activity> 

Attenzione però che la modifica appena realizzata non viene automaticamente recepita dal nostro 
editor in fase di preview. Questo perché il suo unico input è rappresentato dal documento XML del 
layout, mentre nel nostro caso il tema è stato impostato nel file di configurazione dell'intera 
applicazione. Per vedere l'effetto di questa impostazione è sufficiente selezionare il menu a tendina in 
alto e selezionare il tema che si vuole applicare come nella Figura 3.8. 
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Figura 3.8 Selezione del tema da applicazione in fase di preview. 

In risultato è quello nella Figura 3.9, dove permane il problema relativo alresize dell'icona ma dove 
l'action bar è stata comunque eliminata. Notiamo poi come anche il colore di sfondo sia cambiato da 
bianco a nero; questo è l' effètto del tema utilizzato. Prima di proseguire dobbiamo comunque eseguire 
una ulteriore verifica. Una risorsa come quella relativa ai temi è la più soggetta a cambiamenti a 
seconda della versione della piattaforma utilizzata. 
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Figura 3.9 Eliminazione dell'action bar attraverso l'applicazione di un tema. 

Nel nostro caso, come possiamo vedere nella parte alta della preview, il tutto si riferisce alla 
versione 17 dell' API LeveL Cosa succede però nelle versioni precedenti che abbiamo promesso di 
supportare? Il nostro tema era già disponibile nella versione dell' API Level 7? Per verificare la cosa è 
sufficiente aprire il corrispondente menu a tendina e selezionare la relativa versione della piattaforma. 
Attenzione però: veranno mostrate solamente quelle versioni che sono state scaricate e che quindi 
sono disponibili nel nostro tool. Nell'esempio è disponibile solamente la 17, per cui dovremo utilizzare 
l'SDK Manager per scaricare le altre versioni a cui sono interessato. L'ideale sarebbe scaricare e 
testare tutte le versioni ma è comunque bene dire che le principali, specialmente in relazione alla 
gestione dei tempi, sono le seguenti; 

Androìd 2.1 API Level 7 
Android 2.2 API Level 8 
Android 2.3.3 API Level 10 
Android 3.0 API Level 11 
Android 4.0.3 API Level 15 
Android 4.1.2 API Level 16 
Android 4.2.2 API Level 17 

Scaricate queste versioni possiamo verificare se il tema applicato è presente in ognuna di esse. In 
caso di sorprese dovremo utilizzare i corretti qualificatori per ottenere lo stesso effetto con i temi 
disponibili 

NOTA 

Dopo il download degli ambienti relativi agli eventuali API Level mancanti è necessario riavviare 
Android Studio per poterli vedere come nella Figura 3.10. 
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API 15: Android 4.0.3 




API 11: Android 3.0 
API 10: Android 2.3.3 
API 8: Android 2.2 
API 7: Android 2.1 



Figura 3.10 È possibile modificare la preview in base al particolare API Level disponibile. 

Lasciamo al lettore la verifica sulla effettiva uniformità del nostro layout nonostante il cambiamento 
di API Level. 

Risolto quindi il problema relativo all'action bar, ci dedichiamo alla realizzazione di un layout che 
permetta la visualizzazione del fogo dell'applicazione centrato nello schermo, non deformato anche a 
seguito di un diverso orientamento del dispositivo. 

Realizziamo il seguente layout, che contiene un'imageview al proprio interno a cui è stata associato 
il riferimento alla nostra immagine come valore dell'attributo android : src: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 
android : layout_width="match_parent " 
android : layout_height="match_parent "> 
<ImageView 

android : layout_width="wrap_content " 
android: layout_height="wrap_content " 
android: id="@+id/splash_imageview" 
android : src= " gdrawable/ ic_launcher " 
android : layout_gravity=" center " /> 
</FrameLayout> 

Per aggiungere Fimageview nel layout ci sono diverse modalità. La più semplice consiste 
nell' attivare la palette, selezionare il componente e quindi scegliere la posizione nel layout in cui 
inserirlo. Un'altra alternativa è quella di scrivere direttamente il sorgente XML del layout cosa che, 
quando si avrà un po' di esperienza in più, risulterà la soluzione più veloce, grazie anche all'aiuto delle 
funzioni di autocompletamento dell'editor. Notiamo poi come sia stato assegnato un identificatore 
dell' ImageView attraverso l'utilizzo dell'attributo android: id. Sebbene in questo caso specifico la 
cosa non sia necessaria, è buona norma assegnare a ciascun elemento delle nostre interfacce un 
identificatore che ci permetta di referenziarlo da ogni altro punto dell'applicazione. 

Se ora osserviamo la nostra preview (Figura 3.11) rimaniamo delusi; l'immagine è troppo piccola 
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ma sappiamo essere stata una conseguenza della scelta stessa dell'immagine; in realtà tale immagine 
dovrebbe essere più grande. 

La ragione di questo è dovuta alle impostazioni evidenziate nel codice precedente, le quali indicano 
sostanzialmente che la dimensione dell' ImageView dovrà essere sufficiente a contenere l'immagine da 

visualizzare (wrap_content). 




Figura 3.11 Preview della splash utilizzando un'ImageViewe l'icona. 



NOTA 

Nel Capitolo 5 vedremo nel dettaglio il significato di questi attributi che permettono la configurazione 
di alcune regole proprie di ciascun layout. 

Essendo l'icona piccola anche 1' ImageView diventerà piccola. Questo ci dà l'opportunità di parlare 
di un altro importante tipo di risorse, ovvero quelle di tipo dimension. 



Le risorse di tipo dimension 

Nei paragrafi precedenti abbiamo visto come le risorse rappresentino una parte fondamentale di 
ciascuna applicazione Android. Abbiamo inoltre visto che alcuni dei qualificatori più importanti sono 
relativi alle dimensioni e risoluzione dei display. È quindi naturale che si possa avere la necessità di 
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specificare alcune dimensioni dei diversi componenti anch'essi dipendenti dalle caratteristiche dei 
display. Per lare questo la scelta delle risorse è quindi la più naturale e prevede la possibilità di 
utilizzare fino a sei diverse unità di misura. 

La più importante è sicuramente quella indicata con dp (density indipendent pixel), che ci 
permette di rappresentare delle dimensioni fisiche in modo indipendente dalla densità del display del 
dispositivo. Per comprendere bene di cosa si tratti ci aiutiamo con un esempio. Supponiamo di 
definire un componente le cui dimensioni sono specificate in pixel, e precisamente 100 x 100 pixel. In 
un display a media densità (160 dpi) supponiamo che il componente assuma delle dimensioni fisiche 
di 80 x 80 millimetri Questo significa che in 10 mm stanno 8 pixeL A questo punto supponiamo di 
rappresentare lo stesso componente in un display a densità maggiore (per esempio 240 dpi), che sarà 
caratterizzata da un maggior numero di pixel per unità di misura. Se il precedente disponeva di 8 pixel 
per 1 mm ora il nuovo display ne avrà 12. Questo significa che i 100 x 100 pixel assumono una 
dimensione fisica di circa 54^54 mm ovvero più piccola. Attraverso l'utilizzo dell'unità dp il sistema ci 
garantisce che le dimensioni fisiche vengano mantenute, per cui se un componente di 100 x 100 dp ha 
dimensioni 80x80 mm in un display a media densità esso manterrà la stesse dimensioni anche in un 
display ad alta o altissima densità. Sarà cura del dispositivo preoccuparsi di applicare i corretti 
moltiplicatori. Per questo motivo è sempre bene utilizzare dp per la definizione delle eventuali misure 
assolute. 

Nel caso in cui le misure da specificare riguardassero dei testi viene messa a disposizione anche 
l'unità sp (scale indipendent pixel), la quale permette di impostare le dimensioni dei font in modo 
indipendente dalle eventuali configurazioni dell'utente. Attraverso l'unità px possiamo indicare le 
dimensioni in pixel anche se, per quanto visto prima, è sconsigliato mentre con pt facciamo 
riferimento ai punti che solitamente corrispondono a 1/72 di un inch (pollice). Le ultime due unità 
fanno riferimento a delle dimensioni fisiche e precisamente a millimetri (mm) e pollici (in). 

Nel caso della nostra applicazione vogliamo fare in modo che l'immagine della splash abbia una 
dimensione di 250x250 dove l'unità di misura sarà il dp. Definire una risorsa di tipo dimension è 
diverso rispetto a quanto fatto nel caso delle immagini dove ogni file corrisponde a una risorsa 
differente. Una dimensione fa parte del gruppo di risorse raggruppate nella cartella 
src/main/res/values, che contiene dei file XML che sono i contenitori di un numero qualunque di 
risorse associate alle definizioni al suo interno. Per spiegare meglio quanto detto andiamo a vedere il 
contenuto del file dimension. xml creato automaticamente dal progetto: 

<resources> 

<! — Margini di default dello schermo secondo le linee guida Android Design. — > 
<dimen name="activity_horizontal_margin">16dp</dimen> 
<dimen name="activity_vertical_margin">16dp</dimen> 

</ resources> 

In questo caso le risorse sono contenute all'interno di un elemento <resources/> e definite 
attraverso l'elemento di nome <dimen/>. Nel precedente documento XML sono state definite due 
risorse di tipo dimension, a cui sono state associate in modo automatico due costanti della classe r di 
nome 

R. dimen . actìvity_horizontal_margin 
R. dimen . actìvity_vertical_margin 

a cui potremo fare riferimento, dagli altri documenti, attraverso la seguente sintassi: 

@ dimen /acti vi ty_horìzontal_mar gin 
@ dimen / acti vi ty_vertical_mar gin 

Nel nostro esempio il nome del file dimension. xml non ha alcuna importanza nelle regole di 



83 



generazione delle risorse e relative costanti Si tratta semplicemente di un modo per dividere le risorse 
di tipo diverso in file diversi L'unica restrizione riguarda il fatto che non possiamo avere, tra tutte le 
definizioni in values, due risorse dello stesso tipo con lo stesso nome. In quel caso verrebbero 
generate due costanti uguali della classe r, che quindi non compilerebbe. 

Nel nostro caso definiamo una nuova risorsa di tipo dimension che chiamiamo appunto 
S piash_size modificando il file precedente nel seguente modo: 

<resources> 

<! — Margini di default dello schermo secondo le linee guida Android Design. — > 
<dimen name="activity_horizontal_margin">l 6dp</dimen> 
<dìmen name="activity_vertical_margin">l 6dp</dimen> 
<dimen name= " spi ash_s ize">250dp</ dimen> 

</ resources> 

Il layout diventerà quindi il seguente: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<FrameLayout xmlns : android="http : / /schemas . android . com/ apk/res /android" 
android : layout_width="match_parent " 
android : layout_height="match_parent "> 
<ImageVìew 

android: layout_width="@dimen/ splash_size" 
android: layout_height="@dimen/ splash_size" 

android: id="@+id/ splash_imageview" 
android : src=" @drawable/ìc_launcher " 
android: layout_gravìty=" center "/> 
</FrameLayout> 

Per verificare quanto ottenuto ripetiamo quanto fatto nel caso precedente ottenendo il risultato nella 
Figura 3.12, che si può considerare buono, anche se notiamo che nel dispositivo Nexus 10 
l'immagine è ancora troppo piccola. Sfruttiamo quindi le caratteristiche delle risorse per creare una 
risorsa di tipo dimension per quel tipo di dispositivi caratterizzati da un'altissima risoluzione ma 
soprattutto elevate dimensioni 
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Figura 3.12 Preview della splash che utilizza l'icona come immagine. 

Se osserviamo il nostro progetto notiamo la presenza delle cartelle nella Figura 3.13 

values-sw600dp 
values-sw720dp-land 
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Figura 3.13 Utilizzo di qualificatori diversi relativi alle dimensioni del display. 



La prima fa riferimento a quei dispositivi che hanno come dimensione minore quella associata ai 
600 dp. 

Per dimensione minore intendiamo la larghezza se in modalità portrait e l'altezza in modalità 
landscape. Se quindi il nostro dispositivo ha una come dimensione minore un valore uguale o 
maggiore di 600 dp, allora le risorse definite in questa cartella verranno prese in considerazione. La 
seconda cartella riguarda sempre i dispositivi con una dimensione minore ma solo se in modalità 
landscape. In sintesi fa riferimento ai dispositivi la cui altezza supera i 700 dp, come il nostro Nexus 
10. Non ci resta quindi che andare a definire la nostra risorse nel seguente modo nella prima cartella: 

<resources> 

<! — Personalizza le dimensioni originariamente definite in res/values/dimens . xml 
(così come i margini) per dispositivi con sw600dp (per esempio tablet da 7") . — > 
<dimen name= " splash_s i ze " > 3 0 0dp< /dimen> 

</ resources> 

e in quest'altro nella seconda: 

<resources> 

<! — Personalizza le dimensioni originariamente definite in res/values/dimens .xml 
(così come i margini) per dispositivi con sw720dp (per esempio da 10") 
in modalità landscape. — > 
<dimen name="activity_horizontal_margin">12 8dp</ dimen> 
<dimen name=" splash_size " >450dp</dimen> 
</ resources> 

per ottenere il risultato della Figura 3.14, che possiamo finalmente considerare come accettabile. 
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Figura 3.14 Preview attraverso l'utilizzo dei qualificatori considerati. 



Creiamo l'activity per la splash 

Dopo relativa fatica siamo quindi giunti alla realizzazione del layout della splash dell'applicazione, 
ovvero a quella schermata che introduce all'applicazione e che spesso viene sfruttata per eseguire 
alcune operazioni di inizializzazione, che nel nostro caso sono per il momento assenti. Come abbiamo 
accennato, in Android ciascuna schermata è rappresentata da quella che si chiama activity e che 
viene descritta da una specializzazione diretta o indiretta dell'omonima classe del package 
android . app. Prima di descrivere la nostra attività è quindi bene vedere quali sono le caratteristiche 
principali di questo componente fondamentale. 

Come è facile intuire, ogni applicazione Android è composta da più schermate che si susseguono 
sul display a seguito delle azioni dell'utente o di altri particolari eventi come la ricezione di un 
messaggio o di una telefonata. Gran parte del lavoro di un' app Reazione consisterà quindi nel 
descrivere queste schermate e soprattutto la modalità con cui si passa da una all'altra. In tal senso 
assume importanza fondamentale il concetto di task che viene definito come un insieme di attività che 
permettono all'utente di eseguire un determinato lavoro. Come esempio eseguiamo una delle 
app Reazioni presenti nella piattaforma, ovvero Gmail. Lo stato di partenza consiste nella 
visualizzazione della Home, ovvero di quella particolare applicazione che visualizza le altre 
applicazioni del dispositivo che possono essere, in un qualche modo, avviate dall'utente. 

NOTA 

Successivamente vedremo come quella che chiamiamo Home non sia altro che una particolare 
applicazione che, attraverso una propria activity, mostra l'elenco delle attività che possono essere 
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eseguite. Vedremo come questa caratteristica venga mappata nel concetti di intent e intent filter. 

Dalla Home lanciamo quindi Gmail ottenendo l'elenco delle proprie e-mail. A questo punto 
selezioniamo un'e-mail visualizzandone il contenuto. Quello che abbiamo latto, illustrato nella Figura 
3.15, nonè altro che la creazione di un nuovo task in cui le attività che chiamiamo MaiiList e 
MaiiDetaii vengono visualizzate nel display e organizzate secondo una struttura a stack. 



Taskl 




Task 2 




Home 




MaiiDetaii 










MaiiList 









Figura 3.15 Esempio di visualizzazione di task e relativi stack. 



Infatti tutte le attività di un particolare task vengono organizzate (se non esplicitato diversamente 
attraverso l'utilizzo di particolari attributi o flag) in una struttura a stack (pila), con in testa l'activity 
con cui l'utente può interagire in quel momento, che dovrà necessariamente essere visibile. 

Come possiamo vedere nella figura, si hanno due task; quello associato alla Home e quello 
associato alla nostra applicazione di posta. L'attività visibile è quella in cima allo stack associato al 
task dell'applicazione che abbiamo lanciato per seconda. Ora premiamo il pulsante Back. Noteremo 
come lo stato del nostro sistema diventi quello nella Figura 3.16: l'attività relativa al dettaglio del 
messaggio di posta viene eliminata e quindi visualizzata l'attività dello stesso task che la precedeva 
nello stack associato. 

Premendo il pulsante Back non abbiamo fatto altro che estrarre l'attività in cima allo stack 
associato al task attivo in quel momento per poi tornare alla schermate di elenco mail. Premendo 
nuovamente il pulsante Back si ritorna alla visualizzazione della Home. 

Facciamo ora una seconda prova che consiste nell'eseguire nuovamente Gmail arrivando alla 
stessa situazione nella Figura 3.15, ma eseguiamo un'azione diversa ovvero premiamo il pulsante di 
Home. Come abbiamo detto quella che chiamiamo Home è un'applicazione come le altre a cui è 
associato un task e quindi uno stack. Premendo il pulsante di Home non facciamo altro che rendere 
attivo il corrispondente task e quindi visualizzare l'unica attività in cima allo stack, che è la Home. 
Attenzione: le attività dell'applicazione di mail non sono state distrutte ma sono semplicemente non 
attive e quindi non vengono visualizzate. 
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Figura 3.16 Premendo Back abbiamo eliminato l'attività di dettaglio mail. 



A questo punto è sufficiente selezionare nuovamente l'applicazione di mail per riattivare il 
corrispondente task, che quindi si impadronirà del display visualizzando l'attività che ha in cima al 
proprio stack, ovvero il dettaglio della mail precedentemente selezionata. Premendo il pulsante Back 
non làremo altro che ripetere quanto latto in precedenza con l'elimiriazione dell'attività in cima allo 
stack e tutto il resto. 

NOTA 

Nelle ultime versioni di Android, l'applicazione di Home potrebbe essere costituita da più attività che 
permettono, per esempio, di visualizzare i widget disponibili oltre alle applicazioni. L'esperimento 
precedente potrebbe quindi "fallire" nel caso in cui si lanciasse l'applicazione di e-mail da un'attività 
di Home secondaria. In quel caso premendo il pulsante Home dall'applicazione di e-mail si 
tornerebbe all'attività principale di Home. Questo non è dovuto a un errore nel nostro ragionamento 
ma semplicemente a una specifica ed esplicita configurazione. 

Questo semplice esperimento ci permette di lare un' importantissima osservazione che avrà 
ripercussioni sulla modalità con cui la nostra activity verrà scritta. Osserviamo la Figura 3.15, dove 
l'unica attività visualizzata è quella del dettaglio della mail. In questa situazione il sistema potrebbe 
decidere di eliminare le risorse associate alle altre attività che non sono visualizzate e che, dal punto di 
vista dell'interazione con l'utente, sono inutili in quel momento. Potrebbe succedere infatti che il 
sistema rimuova dalla memoria tutto quello che è associato all'attività MailList. Si preoccuperà 
successivamente di ripristinare l'attività qualora si rendesse nuovamente necessaria la sua 
visualizzazione. Sembrerebbe quindi non esistere alcun problema al riguardo se non fosse per il fatto 
che l'attività possiede uno stato. Ma cosa si intende per stato? 

Come abbiamo detto in precedenza e come vedremo nel dettaglio successivamente, un'attività è 
descritta da una classe che estende, direttamente o indirettamente, la classe Activity. Nel momento 
opportuno, il sistema crea un' istanza di questa classe, gli associa un layout (una gerarchia di view) e la 
rende attiva nel display. Come sappiamo una classe è caratterizzata dai propri metodi e variabili 

NOTA 

Solitamente la parte che interessa di una classe è l'insieme delle proprietà e operazioni, che non 
vanno confuse con i concetti di variabili d'istanza o metodi. Una proprietà è ogni particolare 
caratteristica che gli altri oggetti vedono ovvero che possono leggere e/o modificare. Un'operazione 
è sempre pubblica e rappresenta una possibile modalità di interazione con l'oggetto. Una variabile 
d'istanza è una variabile visibile all'interno della classe che la definisce, e un metodo non è sempre 
pubblico. 

Lo stato di un oggetto (istanza di una classe) è dato dall'insieme dei valori dei propri attributi che 
noi rappresenteremo attraverso delle variabili d'istanza. Il sistema non può sapere a priori quali siano 
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le variabili da memorizzare per cui sarà responsabilità dello sviluppatore gestirne la persistenza in 
modo da poterle recuperare in uno scenario come il precedente. Per il momento è importante capire 
che un'attività è soggetta a un ciclo di vita che è fondamentale conoscere per la gestione di scenari 
simili a quello descritto (a cui dedicheremo comunque un fondamentale paragrafo). 

Le attività collaborano quindi nella realizzazione di un insieme di operazioni che l'utente intende 
eseguire e che caratterizzano un particolare task. Un aspetto cruciale di Andro id è dato dal fatto che 
le attività che vediamo all'interno di una stessa applicazione non devono necessariamente appartenere 
all'applicazione stessa. A tale proposito descriviamo un nuovo scenario che consiste nella 
realizzazione di un'applicazione che permette l'invio di un' immagine e un contatto della propria 
rubrica. In questo caso l'applicazione dovrà prevedere sostanzialmente la realizzazione di tre attività. 
La prima è la schermata principale in cui visualizzeremo il numero di cellulare a cui inviare l'immagine 
e una preview dell'immagine stessa. La seconda attività è quella che permette la selezione di un 
contatto, mentre la terza permetterà la selezione di un' immagine dalla gallery. Pensandoci bene, 
queste ultime due attività non sono strettamente legate alla nostra applicazione, in quanto un contatto 
potrebbe essere selezionato per diversi altri motivi, come del resto un' immagine della gallery. Si tratta 
quindi di activity che possono essere utilizzate anche in applicazioni diverse dalla nostra. Esiste quindi 
una nuova modalità di utilizzo delle attività che possiamo definire come "al servizio" delle altre. Anche 
in questo caso vedremo questo concetto nel dettaglio nel corrispondente paragrafo, ma qui è 
importante sottolineare come imo stesso task possa contenere anche attività di applicazioni diverse 
che vengono eseguite in processi diversi A tale proposito Android ci metterà a disposizione degli 
strumenti per fare in modo che queste attività possano comunicare in modo efficiente attraverso 
componenti come il content provider, gli intent, gli intent filler e i sistemi di IPC (Inter Process 
Communication). 

Da questa introduzione capiamo subito che la comprensione dei meccanismi alla base della 
gestione delle activity è fondamentale per la realizzazione di applicazioni riutilizzabili in diversi contesti 
e allo stesso tempo in grado di sfruttare in modo efficiente le risorse della piattaforma. Durante lo 
sviluppo della nostra applicazione vedremo nel dettaglio tutti questi possibili scenari e soprattutto gli 
strumenti offerti dalla piattaforma. 

Ci accingiamo quindi allo sviluppo della nostra splash descritta dalla classe spiashActivity che, 
inizialmente, non farà altro che visualizzare il layout creato in precedenza. Aggiungeremo 
successivamente le regole per il passaggio alla schermata principale dell'applicazione. Selezioniamo 
quindi con il tasto destro del mouse il package associato alla nostra applicazione e scegliamo New > 
Android Component, come mostrato nella Figura 3.18. 
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Figura 3.17 Utilizzo di activity di applicazioni diverse. 
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Figura 3.18 Creazione di una nuova activity. 

Le activity sono solamente uno dei possibili componenti che la piattaforma ci mette a disposizione, 
Android Studio visualizzerà la schermata nella Figura 3.19, attraverso la quale specificheremo il nome 
della corrispondente classe, il tipo di componente e l'etichetta che potrà essere utilizzata in diversi 
contesti che vedremo successivamente. Molto utile e importante è la selezione della casella di 
controllo relativa alla possibilità di indicare questa activity come quella principale dell'applicazione 
(capiremo che cosa questo comporta tra poco). 
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Figura 3.19 Creazione di un'activity. 

Selezionato il pulsante OK si ha quindi la generazione della classe SplashAotiv ity all'interno del 
package che avevamo selezionato in precedenza. Il sorgente della classe generata è molto semplice e 
incompleto: 

public class SplashActivity extends Activity { 

public voìd onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

} 

} 

Notiamo come essa estenda effettivamente la classe Activity e di come definisca il metodo 
onCreate ( ) che vedremo essere fondamentale nella gestione del ciclo di vita di questo componente. 
Abbiamo però imparato che la maggior parte delle attività ha un layout associato che viene 
identificato da una costante della classe r. layout. Per assegnare i layout alla nostra attività 
introduciamo quindi l'istruzione evidenziata nel seguente codice: 

public class SplashActivity extends Activity { 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_splash) ; 

} 

} 

Attraverso il metodo setContentView O ereditato dalla classe Activity, impostiamo come layout 
quello identificato da ima particolare risorsa che risentirà dello stato e caratteristiche del dispositivo 
nel modo descritto. Per il momento tralasciamo il nostro codice e andiamo a verificare che cos'è 
successo all'interno del file di configurazione di nome AndroidManifest . xml, che è diventato il 
seguente: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<manif est xmlns : android="http : / / schema s . android . com/ apk/ res/ android" 
package="uk . co .massimocarli . android . ugho" 
android : versionCode=" 1 " 
android : versionName=" 1 . 0 " > 

<uses-sdk 
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andrò id:minSdkVersion=" 7 " 
android: target SdkVer si on=" 16 " /> 



Opplication 

android: allowBackup="true" 
android: icon=" @drawable/ ic_launcher" 
android: label=" Sstring/ app_name" 
android: theme="@style/AppTheme " > 
<activity 

android : theme="@ android : style/Theme . NoTitleBar . Fullscreen" 
android: name="uk . co . massimocarli . android . ugno .MainActivity" 
android: label="@string/ app_name" > 
<intent-f ilter> 

<action android: name="android. intent . action . MAIN" /> 

<category android : name="android. intent . category . LAUNCHER" /> 
</intent-f ilter> 
</activity> 
<activity 

android: name=" . SplashActivity" 
android: label="SplashActivity"> 
<intent-f ilter> 

<action android :name=" android. intent .action. MAIN" /> 
<category android: name=" android. intent . category . LAUNCHER" /> 
</intent-f ilter> 
</activity> 
</ application> 
</manif est> 

Nel documento XML precedente abbiamo evidenziato quello che è stato introdotto a seguito della 
selezione della casella di controllo in làse di creazione dell'attività. È bene sottolineare da subito come 
la reazione di una classe che estende Activity non sia sufficiente per la sua esecuzione all'interno 
della nostra applicazione; essa deve essere registrata attraverso il documento di configurazione 
affinché il dispositivo ne conosca le caratteristiche e sappia in ogni momento se e quando attivarla. 
L'effetto della selezione della casella di controllo non è comunque la registrazione dell'attività, ma 
l'utilizzo della seguente definizione è di grandissima importanza, e per comprenderla abbiamo bisogno 
del concetto di intent e intent filter. 

<intent-f ilter> 

<action android: name=" android. intent . action. MAIN "/> 

<category android: name=" android. intent . category . LAUNCHER" /> 
</ intent-f ilter> 



I concetti di intent e intent filter 

Una delle principali caratteristiche della piattaforma Android è quella di essere open, non solamente 
per il fatto di permettere l'accesso ai sorgenti ma soprattutto perché gli strumenti che abbiamo a 
disposizione per la realizzazione delle nostre applicazioni sono esattamente quelli che sono stati 
utilizzati per la realizzazione delle applicazioni predefinite. Questo significa che non solo possiamo 
accedere e utilizzare componente esistenti come la rubrica, la gallery e altro, ma possiamo addirittura 
crearne di nostri e quindi sostituirli con gli esistenti Tutto questo è reso possibile attraverso i concetti 
di intent e intent filter che accenniamo in questa fase ma che approfondiremo successivamente. 
Supponiamo di voler realizzare un'applicazione molto semplice che permetta l'inserimento dell'URL 
di una pagina per poi visualizzare la corrispondente risorsa all'interno di un browser. Nella peggiore 
delle ipotesi la nostra applicazione dovrebbe realizzare un browser, attività che possiamo considerare 
abbastanza improponibile. Quello che succede è invece l'utilizzo del browser del nostro dispositivo, o 
meglio, di uno dei browser installati nel dispositivo. La nostra applicazione non dovrà sapere chi sarà 
il componente che andrà a visualizzare la pagina ma creerà un intent all'interno del quale vi saranno le 
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informazioni relative all'azione da eseguire (in questo caso una view) e al tipo di dato su cui la stessa 
dovrà essere eseguita, che in questo caso sarà un semplice URL corrispondente a una pagina HTML. 
Una volta incapsulate le informazioni all'interno di un intent il sistema ci permetterà di "lanciarlo" nella 
speranza che venga raccolto da un qualche componente in grado di gestirlo. Ma come fa un 
componente a dire al sistema di essere in grado di gestire alcune azioni su un particolare insieme di 
dati? In sintesi, come fanno tutti i browser a dire al sistema di essere in grado di visualizzare pagine 
web? Questa è la funzione dell' intent filter. Al momento del lancio di un intent, il sistema esegue 
un'operazione che si chiama di intent resolution e che consente di valutare tutti gli intent filter 
registratinei vari AndroidManif est .xml scegliendo quello o quelli più idonei. Potrebbe infatti capitare 
che uno stesso intent possa essere gestito da più componenti di applicazioni diverse. Nel nostro 
esempio potremmo aver installato Chrome insieme a Firefox. In questi casi il sistema proporrà una 
finestra che permetterà all'utente di scegliere l'applicazione preferita. Per non rendere questa 
operazione frustrante è comunque possibile impostare una delle applicazioni come quella di default, 
evitando quindi tale passo aggiuntivo. 

Torniamo quindi alla nostra amata splash che è stata aggiunta nell' AndroidManif est . xml attraverso 
la definizione che riproponiamo per semplicità e che ci accingiamo a descrivere nel dettaglio anche 
alla luce di quanto detto sopra: 

<activity 

androidi name=" . SplashActivity" 
androidi label="SplashActivity"> 
<intent-f ilter> 

<action androidi name="android. intent . action .MAIN"/> 
<category androidi name="android. intent . category . LAUNCHER"/> 
</intent-f ilter> 
</activity> 

Come tutte le attività, anche quella di splash viene definita attraverso un elemento <activity/> 
contenuto all'interno dell'elemento <appiication/>. L'attributo più importante è sicuramente 
android : name, che ci permette di indicare qual è la classe corrispondente. Il lettore più attento avrà 
sicuramente notato come il nome della classe non comprenda il package. Questa notazione è 
possibile solamente perché la classe è contenuta all'interno del package associato all'applicazione e 
quindi può essere specificata in modo relativo rispetto a esso. L'attributo successivo è 
androidi label, che ha diverse funzioni. Nel caso in cui l'applicazione avesse più attività che si 
possono lanciare direttamente dalla Home del dispositivo, questo è il nome associato alla 
corrispondente icona. Un'attività di un'applicazione potrebbe poi essere considerata come una 
particolare azione di un'altra. Quello indicato dall'attributo label sarà quindi il nome con cui tale 
opzione sarà visibile in un menu Nel nostro caso decidiamo di eliminare questo attributo perché 
intendiamo associare l'etichetta specificata attraverso l'omonimo attributo dell'elemento 
<appiìcation/>. La principale ragione di questa scelta sta nel fatto che la nostra attività non viene 
richiamata da nessun' altra e soprattutto il valore che avevamo assegnato non faceva riferimento a una 
risorsa, sfruttandone la caratteristica di poter essere internazionalizzata attraverso l'uso di qualificatori. 

NOTA 

Quelli che vediamo qui sono solo alcuni dei possibili attributi dell'elemento <activity/>. Ne vedremo 
altri durante lo sviluppo dell'applicazione. Per una visione completa il lettore può consultare l'elenco 

e la relativa descrizione all'indiriZZO http://developer.android.com/guide/topics/manifest/activitY-element.html. 

Di seguito abbiamo quindi la definizione di un intent filter attraverso l'omonimo elemento <intent- 
f iiter/>, il quale permette di indicare l'insieme degli intent a cui la nostra attività è in grado di 
rispondere. In questo caso abbiamo un unico elemento di questo tipo ma un'attività, o altro 
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componente, potrebbe essere sensibile a più intent diversi e quindi comportarsi in modo differente a 
seconda delle relative proprietà. Ma a cosa sarà in grado di rispondere la nostra attività di splash? 
Ciascun intent è caratterizzato da mi' azione, che non è altro che una stringa che solitamente segue la 
convenzione 

<package applicazione> . action . <NomeAzione>_ACTION 

Molte di queste azioni sono già disponibili nella piattaforma come quella relativa alla visualizzazione, 
editing e altro ancora. Affinché un componente sia sensibile a un particolare intent è assolutamente 
necessario che questo abbia la relativa azione tra quelle definite attraverso l'elemento <action/>. Nel 
nostro caso la nostra attività sarà sensibile agli intent che avranno come azione (che è unica per 
ciascun intent) quella standard identificata dalla stringa 

android. intent . action . MAIN 

Si tratta dell'azione associata all' intent che il sistema lancia quando selezioniamo l'icona di 
un'applicazione nella Home del dispositivo. Questo sta a significare che attraverso la definizione 

<action android: name=" android . intent . action .MAIN" / > 

abbiamo candidato la nostra attività a essere eseguita a seguito della selezione dell'icona 
dell'applicazione. In precedenza abbiamo accennato al tipo di dato su cui l'azione viene eseguita. Si 
tratta di un' informazione descritta attraverso l'elemento <data/>, che in questo caso non viene 
utilizzata ma che vedremo essere di fondamentale importanza successivamente. Quella che invece 
deve essere definita è la terza proprietà di un intent, ovvero la categoria descritta attraverso 
l'elemento <category/>. In questo caso un intent può avere un numero qualunque di category. 
Affinché un componente sia sensibile all'intent è necessario che tra quelle definite attraverso elementi 
di questo tipo: 

<category android: name=" android. intent . category . LAUNCHER" / > 

vi siano tutte quelle dell'intent stesso. Ogni intent, se non definito diversamente, ha comunque una 
category di default associata alla costante 

android. intent . category . DEFAULT 

che quindi bisogna ricordarsi di definire quando necessario. 

Riassumendo, attraverso la definizione di un elemento <intent-fiiter/> nel file di configurazione 
AndroidManif est . xml abbiamo candidato la nostra attività di splash alla sua esecuzione a seguito 
della selezione della corrispondente icona nella Home del dispositivo. Abbiamo in sintesi impostato 
questa activity come l'attività principale della nostra applicazione. 

Attenzione: nel file di configurazione è presente ancora la seguente definizione relativa all'attività 
MainActivity creata in modo automatico in fase di creazione del progetto: 

<activity 

android: theme="@ android: style/Theme .NoTitleBar .Fullscreen" 

android: name="uk . co . massimocarli . android . ugno .MainActivity" 
android: label="@string/app_name" > 

<intent-f ilter> 

<action android: name="android . intent . action .MAIN" /> 
<category android : name="android. intent . category . LAUNCHER" /> 

</ intent-f ilter> 
</ activity> 

Anch'essa era candidata a essere l' activity principale ma soprattutto era quella a cui avevamo 
associato il tema relativo al fullscreen. Notiamo infine come venga utilizzato come etichetta il nome 
dell'applicazione attraverso la corrispondente risorsa di tipo String. 

Alla luce di quanto detto modifichiamo quindi il file di configurazione nel seguente modo, dove 
abbiamo evidenziato le parti di interesse: 



<?xml version="l . 0" encoding="utf-8" ?> 

<manif est xmlns : android="http : / / schema s . android . com/ apk/ res/android" 
package="uk . co .massimocarli . android . ugho" 
android: ver sionCode=" 1 " 
android: versionName=" 1 . 0"> 
<uses-sdk 

android :minSdkVersion=" 7 " 
android : target SdkVersion=" 1 6" / > 
<application 

android: allowBackup="true" 

android : icon=" @drawable/ic_launcher " 

android: label=" @string/app_name" 

android: theme=" @sty le/ AppTheme"> 

octivity android: name=" .MainActivity" /> 

<activity 

android : theme= " @ android : style/Theme . NoTit leBar . Fui 1 screen " 

android : name=" . SplashActivity " 
android : label= " @string/app_name " > 

<intent-f ilter> 

<action android: name=" android. intent . action . MAIN" /> 
<category android : name=" android. intent . category . LAUNCHER" /> 
</intent-f ilter> 
</activity> 
</ application> 
</manifest> 

Abbiamo quindi portato la definizione del tema in corrispondenza della splash insieme all'utilizzo 
della risorsa associata al nome dell'applicazione come valore dell'attributo label. Un aspetto 
fondamentale che vedremo molto presto è quello relativo alla definizione dell'attività MainActivity, 
che non definisce alcun <intent-f nter/>. È il caso in cui la scelta del componente da attivare non si 
ottenga attraverso un processo di intent resolution ma venga definito in modo esplicito attraverso 
quello che si chiama appunto intent esplicito, che sarà argomento del successivo paragrafo. 

Prima di procedere, facciamo comunque una veloce verifica del punto in cui siamo arrivati 
eseguendo la nostra applicazione nell'AVD creato in precedenza. Intanto osserviamo come il risultato 
sia quello nella Figura 3.20, come in effetti ci aspettavamo. 

Selezioniamo il pulsante Back in basso a sinistra e andiamo nella Home del dispositivo, dove 
notiamo essere presente la nostra icona. 

Per verificare se la nostra definizione era corretta, ma dopo la precedente esecuzione non dovremo 
avere problemi, è sufficiente selezionare l'icona per vedere nuovamente visualizzato il nostro layout di 
splash associato alla corrispondente attività. 

Concludiamo però il paragrafo con una domanda che il lettore si sarà sicuramente posto. Abbiamo 
visto come far siche un'attività sia lanciata a seguito della selezione di un'icona, ma come fa la Home 
a sapere quali sono le applicazioni da visualizzare? Tutte le informazioni relative ai componenti da 
eseguire sono gestite da un componente che si chiama PackageManager. Tra le diverse funzioni 
offerte da questo componente ve ne sono alcune che permettono di eseguire delle query e quindi 
sapere, dato un particolare intent, quali sono i componenti in grado di gestirlo. 



96 




Figura 3.20 Avvio dell'applicazione e visualizzazione della splash. 
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Figura 3.21 L'icona della nostra applicazione nella home del dispositivo. 

L'applicazione di Home non fa altro che utilizzare queste funzioni per accedere all'elenco di 
componenti in grado di rispondere a un intent associato all'azione MAIN e alla categoria 
LA UNCHER per poi visualizzarli nel modo voluto attraverso i propri layout. Infime, questa 
applicazione di Home dovrà gestire l'azione di selezione. 

Intent esplicito e passaggio all'attività successiva 

Quando abbiamo eseguito la nostra applicazione abbiamo ottenuto, come voluto, la visualizzazione 
dell'attività di splash con il layout che abbiamo progettato. Non è un granché graficamente, ma questo 
al momento non ci preoccupa. Quello di cui vogliamo occuparci ora è dare alla nostra splash un 
comportamento idoneo che preveda che si passi all'attività successiva a seguito di un evento di touch 
oppure in corrispondenza del passaggio di un periodo configurabile di tempo. Per complicarci 
leggermente la vita supponiamo che l'evento di touch non possa avvenire troppo presto. Per fare 
questo abbiamo realizzato la seguente classe, che andiamo a descrivere negli aspetti fondamentali che 
non sono, specialmente in questo momento, banali 

NOTA 

Per motivi di spazio i sorgenti delle classi descritti qui saranno senza la definizione degli import e 
dei commenti, che comunque sono disponibili nel codice sorgente originale che invitiamo a 
consultare durante la lettura. 

Come fatto in precedenza, seguiamo un percorso che ci permetterà di affinare sempre più il codice 
della nostra activity, che nella prima versione è il seguente descritto dalla classe SplashActivityl 

public class SplashActìvity extends Activity { 

private static final long MIN_WAIT_INTERVAL = 1500L; 
private static final long MAX_WAIT_INTERVAL = 3000L; 
private static final int GO_AHEAD_WHAT = 1; 
private long mStartTime; 
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private boolean mlsDone; 



private Handler mHandler = new Handler() { 
@Override 

public void handleMessage (Message msg) { 
switch (msg.what) { 

case GO_AHEAD_WHAT : 

long elapsedTime = SystemClock . uptimeMillis ( ) - mStartTime; 
ìf (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 
mlsDone = true; 
goAhead ( ) ; 

} 

break; 

} 

} 

}; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_splash) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 

mStartTime = SystemClock . uptimeMillis () ; 

final Message goAheadMessage = mHandler . obtainMessage ( GO_AHEAD_WHAT ) ; 
mHandler . sendMessageAtTime (goAheadMessage, mStartTime + MAX_WAIT_INTERVAL) ; 

} 

private void goAheadO { 

final Intent intent = new Intent (this, FìrstAccessActìvity . class ) ; 
startActivity (intent) ; 
finish ( ) ; 

} 

} 

Innanzitutto notiamo come la nostra classe estenda direttamente la classe Activity. Vedremo a suo 
tempo come talvolta sia necessario e auspicabile estendere altre specializzazioni che ci permetteranno 
di accedere a funzionalità particolari Nella parte iniziale definiamo quindi le costanti 
min_wait_interval e max_wait_interval, che conterranno rispettivamente i valori relativi 
all'intervallo minimo da attendere per il passaggio all'attività successiva e quello in cui il passaggio 
avverrà in automatico. Gli intervalli vengono rappresentati in millisecondi e memorizzati in costanti di 
tipo long. Per il momento tralasciamo il significato della costante go_ahead_what e passiamo alla 
definizione di due variabili che rappresentano rispettivamente l'istante della prima visualizzazione 
(variabile tstartTime) e l'intòrmazione relativa al fatto che il passaggio all'attività seguente sia già 
stato realizzato (variabile misDone). Questa variabile risulta utile nel caso in cui si decidesse di uscire 
dall'applicazione prima del passaggio all'attività successiva. Se non impostassimo a false il suo 
valore noteremmo, nonostante la chiusura dell'applicazione, il passaggio all'attività successiva, in 
quanto comunque il trigger che impostiamo è stato definito. Stiamo parlando di quanto definito nel 
metodo onstart ( ) , che è un metodo molto importante che la nostra classe eredita e che fa parte del 
ciclo di vita di cui parleremo nel dettaglio successivamente. Per il momento consideriamolo come un 
metodo di callback invocato in corrispondenza alla visualizzazione del layout associato a un' activity 
nel display. Nel nostro caso non facciamo altro che valorizzare la variabile mStartTime con il valore 
ottenuto dal metodo statico uptimeMillis o della classe SystemClock. Chi ha esperienza di 
programmazione Java si sarà chiesto il perché non sia stato utilizzato il metodo currentTimeMìiiis o 
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della classe system. Entrambi sono espressi in millisecondi. Il primo fa riferimento al tempo di non 
sleep trascorso dal dispositivo da quando è stato acceso, mentre il secondo è una misura assoluta del 
tempo attuale: 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 

mStartTime = SystemClock . uptimeMillis () ; 

final Message goAheadMessage = mHandler . obtainMessage (GOAHEADWHAT) ; 
mHandler . sendMessageAtTime (goAheadMessage, mStartTime + MAXWAIT INTERVAL) ; 

} 

La ragione della nostra scelta sta nelle istruzioni successive, dove utilizziamo un oggetto che ha una 
grandissima importanza nell'architettura Android e che è descritto dalla classe andrò id . os . Handler. 
Nel Capitolo 9 vedremo nel dettaglio di cosa si tratta e del perché vi sia la necessità di un 
componente di questo tipo. Per il momento diciamo semplicemente che si tratta di un oggetto in grado 
di elaborare dei comandi a seguito della ricezione di un messaggio all'interno di un particolare thread. 

NOTA 

Vedremo che i messaggi inviati a un particolare handler vengono inseriti all'interno di una coda che 
lo stesso handler elaborerà all'interno del thread a esso associato. 

Nel codice precedente vediamo infatti come, attraverso il metodo obtainMessage o della classe 
handler si sia creato un messaggio che poi è stato inviato alla stesso handler attraverso il metodo 
sendMessageAtTime ( ) . Non tutti i messaggi sono associati alla stessa operazione e un particolare 
handler può essere utilizzato per elaborare messaggi diversi caratterizzati da quello che si chiama 
what. Quando abbiamo creato il messaggio abbiamo quindi specificato, attraverso la costante 
go_ahead_what, ilwhat, ovvero un valore intero che caratterizza il tipo di messaggio e quindi 
l'operazione che dovrà essere eseguita di conseguenza. Infine il metodo sendMessageAtTime o ci 
permette di fare in modo che il messaggio venga inviato in un preciso istante che viene definito 
appunto attraverso un tempo che non è assoluto, ma che fa riferimento alle stesse regole del metodo 
uptimeMillis o e che quindi ne giustifica l'utilizzo. 

Fino a qui abbiamo fatto in modo che, in corrispondenza della visualizzazione dell'immagine di 
splash e quindi dell' esecuzione del metodo onstart ( ) , venisse programmato un evento associato 
all'invio di un messaggio all'handler per il passaggio all'attività successiva. L'elaborazione di questo 
messaggio avviene nell'handler che abbiamo definito nel seguente modo: 

private Handler mHandler = new Handler () { 
SOverride 

public void handleMessage (Message msg) { 
switch (msg. what) { 

case GO_AHEAD_WHAT : 

long elapsedTime = SystemClock . uptimeMillis ( ) - mStartTime; 
if (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 

mlsDone = true; 

goAhead ( ) ; 

} 

break; 

} 

} 

}; 

Attraverso questa sintassi, caratteristica delle classi anonime, abbiamo creato un'istanza di handler 
facendo l'override del metodo handleMessage ( ) , che è appunto il metodo responsabile della 
ricezione ed elaborazione dei messaggi Notiamo come sia stato poi utilizzata la proprietà what 



100 



dell'oggetto di tipo Message ottenuto come parametro per individuare il tipo di operazione da 
eseguire. 
NOTA 

Nel nostro caso si tratta di un'unica operazione, ma è sempre bene pensare da subito alla 
possibilità di aggiungerne di nuove associate a diversi valori dell'attributo what. 

Nel caso specifico abbiamo calcolato il tempo passato dall'avvio per capire se ha superato o meno 
il valore di min_wait_interval. Nel caso in cui sia trascorso abbastanza tempo e soprattutto il 
passaggio all'attività non sia già avvenuto o non si sia usciti prima, non facciamo altro che impostare a 
true la variabile misDone e quindi invocare il metodo goAhead ( ) , che contiene finalmente il codice per 
passare all'attività principale dell'applicazione descritta precedentemente dalla classe MainActivity, 
ma che abbiamo rmorninato in FirstAccessActivity in quanto cipermetterà di fare alcune operazioni 
relative al solo primo accesso. 

NOTA 

Il lettore si sarà di certo chiesto del perché si debba passare per un handler invece che utilizzare un 
timer o semplicemente un thread per la gestione dell'attesa. In effetti avremmo potuto seguire anche 
questo approccio, ma da un lato abbiamo sfruttato la possibilità del metodo sendMessageAtTime <> e 
dell'altro abbiamo preferito introdurre da subito un concetto di estrema importanza, come vedremo 
durante lo sviluppo degli altri componenti dell'applicazione. 

Finalmente siamo giunti al metodo che contiene la logica del passaggio all'attività successiva, 
ovvero il metodo goAheadO, che riprendiamo qui per convenienza: 

private void goAheadO { 

final Intent intent = new Intent (this , FirstAccessActivity . class) ; 
startActivity (intent) ; 
finish ( ) ; 

} 

Anche in questo caso esistono tre importantissimi concetti in sole tre righe di codice. La prima riga 
crea quello che si chiama intent esplicito e che permette l'attivazione di un componente della 
piattaforma che si conosce a priori In questo caso sappiamo già quale componente dovrà essere 
attivato, che non sarà quindi soggetto alla regola di intent resolution. Qui il costruttore dell' intent 
prevede semplicemente un riferimento all'attività stessa (o meglio a ima sua astrazione che si chiama 
Context) e quindi l'oggetto di tipo ciass<?> relativo al componente da attivare, che nel nostro caso è 
quello corrispondente all'activity descritta dalla classe FirstAccessActivity. 

NOTA 

Nello studio della piattaforma Android vedremo come gran parte dei metodi a disposizione utilizzi un 
riferimento a un oggetto di tipo context, che rappresenta sostanzialmente un'astrazione di ciascun 
componente gestito dalla piattaforma e che permetterà l'interazione con essa. Vedremo infatti come 
un'activity o un service siano effettivamente specializzazioni di questa classe. 

Attraverso il metodo startActivity ( ) che la nostra classe eredita per il fatto di aver esteso una 
specializzazione del Context, possiamo richiedere il lancio dell' intent e quindi, in questo caso, 
F attivazione del componente in modo esplicito. Per quanto detto sopra in relazione alla gestione dei 
task, la seconda attività verrebbe posizionata in cima allo stesso stack. Se non specificato 
diversamente, la splash rimarrebbe quindi nello stack e sarebbe possibile ritornarci semplicemente 
selezionando il tasto di back. Questo, nel caso di ima schermata di splash non deve succedere, per 
cui utilizziamo il metodo finish ( ) , che di fatto elimina l'attività dallo stack. Attraverso l'utilizzo di 
questo metodo, la pressione del pulsante Back dall'attività appena lanciata provoca l'uscita 
dall'applicazione come voluto. 
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Attenzione ai memory leak 

L'activity appena realizzata, che chiediamo al lettore di eseguire e testare, presenta però alcuni 
problemi dovuti all'evento di touch ancora non implementato. Uno di questi è legato alla gestione 
della memoria argomento di fondamentale importanza soprattutto in applicazioni commerciali Come 
in altri campi, uno dei modi migliori per evitare questo tipo di problemi è la prevenzione e quindi 
l'utilizzo di pattern che permettano di evitare un ricorso smisurato alla memoria. Uno dei principali 
nemici degli sviluppatori di applicazioni Andro id è infatti quello che si manifesta attraverso un errore di 
tipo Out of Memory e che porta inesorabilmente al crash dell'applicazione e quindi a giudizi negativi 
sul Play Store. A dire il vero quando un' applicazione ha di questi problemi non è sempre colpa dello 
sviluppatore, in quanto la memoria, come alcuni componenti, viene comunque condivisa da più 
applicazioni. Una delle principali cause è il cosiddetto memory leak. Come sappiamo Java, e anche 
Andro id da un po' diversioni, prevede l'utilizzo di un garbage collector, ovvero di un processo che, 
a intervalli non prevedibili, scandisce la memoria a caccia di oggetti non più utilizzati per poterli 
eliminare. Ma come fa il GC a sapere se un oggetto non è più utilizzato? La regola dice che un 
oggetto non è più utilizzato, e quindi è un forte candidato alla liberazione della relativa memoria, 
quando non esiste alcun riferimento vivo. Un riferimento è vivo quando viene utilizzato da un thread 
in esecuzione odaun riferimento statico. 

NOTA 

Questa non è la sede per approfondire questo concetto, ma non sempre disporre di un GC è una 
cosa positiva dal punto di vista delle performance. Anche il lavoro del GC è qualcosa che necessita 
di risorse, per cui può comunque capitare che la sua esecuzione porti a dei rallentamenti 
nell'esecuzione del codice dell'applicazione, spesso anche percepibili da parte dell'utente. 

In un mondo ideale il GC sarebbe sufficiente per una buona gestione della memoria. I problemi si 
verificano però quando un oggetto che dovrebbe essere eliminato rimane in memoria perché 
mantenuto vivo da collegamenti diventati inutili ma comunque esistenti e vivi Questa è proprio la 
situazione che caratterizza un memory leak e che bisogna evitare. Prima di descrivere qual è il 
problema nel listato precedente, vediamo un caso tipico di memory leak che si verifica in Java la cui 
soluzione ci sarà utile. Prendiamo il caso tipico di ima sorgente di un evento con i suoiN listener, che 
sono degli oggetti istanze di classi che implementano delle interfacce del tipo: 

public interface MyEventListener { 

void eventTriggered (MyEvent e); 

} 

Disolito le informazioni dell'evento sono incapsulate all'interno di una classe del tipo MyEvent e 
l'interfaccia che i listener dovranno implementare avrà nome del tipo liyEventListener. Le interfacce 
descriveranno poi un insieme di operazioni caratterizzate dall'avere un unico parametro del tipo 
corrispondente all'evento stesso. Fin qui niente di particolare, inquanto il problema sta spesso nella 
sorgente, che è caratterizzata dall'avere dei metodi del tipo: 

public void addMyEventListener (MyEventListener listener) 
public void removeMyEventListener (MyEventListener listener) 

che permettono appunto ai vari listener di registrarsi Ma come fa la sorgente a mantenere i 
riferimenti dei propri listener? Di solito utilizza un codice del tipo: 

private List<MyEventListener> listeners = new LinkedList<MyEventListener> ( ) ; 

public void addMyEventListener (MyEventListener listener) { 
listeners . add (listener) ; 
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} 



public void removeMyEventListener (MyEventListener listener) { 
listeners . remove (listener) ; 

} 

I problemi però si verificano quando il listener è un oggetto che terminerebbe la sua vita se non 
fosse per quel riferimento all'interno della sorgente che ci siamo dimenticati di deregistrare invocando 
il metodo removeMyListener ( ) . Sebbene l'oggetto non abbia più ragione di esistere, la memoria da 
esso occupata non viene liberata dal GC perché comunque esiste ancora un suo riferimento vivo 
all'interno della sorgente la quale, per giunta, gli notificherà ancora l'evento. 

Fortunatamente Java ci viene in aiuto attraverso la classe weakReference<±>, che permette di 
ottenere il riferimento a un oggetto di tipo t ma senza che questo venga tenuto in considerazione dal 
GC al momento della scansione degli oggetti da eliminare. In pratica, avere dei riferimenti a un 
oggetto di tipo weak, ovvero fatti attraverso oggetti di tipo weakReference, equivale a non avere 
nessuno ai fini della candidatura dell'oggetto alla sua eliminazione. Tornando all'esempio precedente, 
un codice di questo tipo: 

private List<WeakRef erence<MyEventListener>> listeners = 
new LinkedList<WeakRef erence<MyEventListener>> ( ) ; 

public void addMyEventListener (MyEventListener listener) { 

listeners . add (new WeakRef erence<MyEventListener> (listener) ) ; 

} 

eliminerebbe il problema precedente in quanto i riferimenti che la sorgente ha verso i listener non 
sarebbero ora tenuti in considerazione da parte del GC. In questo caso la sorgente dovrà comunque 
verificare l'esistenza del listener nel momento della notifica e quindi provvedere all'eliminazione dei 
listener "morti" dalla lista. Potrebbe quindi utilizzare del codice del tipo: 

List<WeakRef erence<?>> toDelete = new LinkedList<WeakRef erence<?>> ( ) ; 
for (WeakRef erence<MyEventLìstener> ref : listeners) { 
MyEventListener listener = ref.getO; 
if (listener != nuli) { 

listener. EventTriggered (e) ; 
} else { 

toDelete . add (ref) ; 

} 

} 

// Eliminiamo i riferimenti morti dalla lista 
for (WeakRef erence<?> ref: toDelete) { 
listeners . remove (ref) ; 

} 

// Clean the toDelete 
toDelele = nuli; 

Abbiamo infatti creato una lista dei riferimenti morti per i quali il corrispondente oggetto è stato 
eliminato dal GC. La presenza o meno dei riferimenti è stata eseguita durante la notifica dell'evento. 
Abbiamo quindi eliminato dall'elenco dei listener i riferimenti morti e quindi messo a nuli il riferimento 
della lista. È importante dire che quella descritta è una regola generale che comunque non tiene conto 
di importanti considerazioni legate all'accesso concorrente ai diversi oggetti 

Abbiamo così capito che l'utilizzo di weakReference può essere una buona soluzione a un 
problema di memory leak, ma non abbiamo ancora visto dove questo problema sia presente nella 
nostra splash Per comprenderlo a fondo dobbiamo tornare un attimo indietro al concetto di handler, 
che abbiamo detto essere un oggetto in grado di eseguire una serie di comandi associati a dei 
messaggi 

Quando un'applicazione Andro id viene avviata, il sistema le associa un'istanza di un oggetto che 
prende il nome di looper. Si tratta sostanzialmente di un ciclo, in esecuzione nel thread principale 



dell'applicazione che estrae oggetti di tipo Message da una coda per poi eseguirli uno dopo l'altro. In 
questa coda ci sono i messaggi relativi alle chiamate ai metodi di callback di un'attività, alla gestione 
degli eventi e altro ancora. L'interazione con questo thread avviene infatti attraverso la creazione di 
messaggi che vengono inseriti in una coda gestita dal looper, la cui vita termina con l'applicazione. 
NOTA 

Lo Ul Thread o thread principale è quello responsabile della visualizzazione dei componenti e 
gestione degli eventi. Come vedremo nel Capitolo 9, sarà compito dello sviluppatore fare in modo 
che in questo thread vengano eseguite solamente le operazioni di interazione con la Ul, eseguendo 
in altri thread operazioni di accesso alla rete o comunque operazioni che possono rallentare o 
addirittura bloccare l'interattività dell'applicazione. 

Unhandler creato all'interno di un thread viene implicitamente associato al corrispondente looper. 
Se quindi un handler, come il nostro, viene istanziato all'interno del thread principale dell'applicazione, 
a esso viene associato il corrispondente looper creato nel momento di avvio dell'applicazione. Ogni 
messaggio che viene inviato a una coda mantiene anche un riferimento all'handler utilizzato. Questo 
per fere in modo che il looper invochi il suo metodo handleMessage o di cui abbiamo fetta l'override. 
Abbiamo capito che ogni messaggio inviato attraverso un handler mantiene un riferimento all'handler 
stesso. Questo significa che se un messaggio dovesse restare in coda per un tempo lungo, lo stesso 
varrebbe anche per l'handler, che non verrebbe quindi eliminato dal GC durante quel tempo. A dire il 
vero questo non sarebbe un problema: se un messaggio deve essere elaborato ha comunque bisogno 
di un handler che contenga la logica ditale elaborazione. Il problema si ha invece quando l'handler 
viene creato come classe anonima: 

private Handler mHandler = new Handler ( ) { 
SOverride 

public void handleMessage (Message msg) { 
switch (msg.what) { 

case GO_AHEAD_WHAT : 

long elapsedTime = SystemClock . uptimeMillis ( ) - mStartTime; 
ìf (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 
mlsDone = true; 
goAhead ( ) ; 

} 

break; 

} 

} 

}; 

In Java una classe interna anonima contiene sempre un riferimento implicito all'istanza in cui è stata 
creata. Questo significa che il nostro handler mantiene un riferimento, purtroppo strong (forte) 
aU'activity nel quale è stato creato. Ecco che se il nostro Message porta con sé il corrispondente 
handler quest'ultimo porta con sé il riferimento aU'activity, che a sua volta porta con sé il riferimento al 
layout e a tutti i suoi componenti Come conseguenza abbiamo che se il messaggio venisse elaborato 
dopo che l'activity è terminata a seguito, per esempio, della pressione del pulsante Back, comunque 
questa non verrebbe eliminata dal GC come invece dovrebbe essere. Per risolvere questo problema 
bisogna quindi fere in modo che l'handler non porti con sé un riferimento forte all'attività. La soluzione 
è quella descritta nel seguente codice, che abbiamo inserito all'interno della classe 
NoLeakSpiashActivity e di cui riportiamo solo la parte di interesse: 

private UiHandler mHandler; 

private static class UiHandler extends Handler { 

private WeakReference<NoLeakSplashActivity> mActivityRef ; 
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public UiHandler ( final NoLeakSplashActivity srcActivity) { 

this .mActivityRef = new WeakReference<NoLeakSplashActivity> (srcActivity) ; 

} 

SOverride 

public void handleMessage (Message msg) { 

final NoLeakSplashActivity srcActivity = this .mActivityRef . get () ; 
if (srcActivity == nuli) { 
return ; 

} 

switch (msg.what) { 

case GO_AHEAD_WHAT : 

long elapsedTime = SystemClock . uptimeMillis ( ) 

if (elapsedTime >= MIN_WAIT_INTERVAL && ! srcActivity . mlsDone ) { 
srcActivity .mlsDone = true; 
srcActivity . goAhead ( ) ; 

} 

break; 

} 

} 

} 

Innanzitutto la classe anonima è stata sostituita con una classe interna statica. Per chi non è esperto 
di Java ricordiamo che una classe interna può essere statica oppure no. Nel primo caso il legame che 
esiste tra la classe interna e quella esterna è logico, come quando si descrive la relazione tra un 
elemento di un contenitore e il contenitore stesso. Questo significa che una particolare istanza della 
classe interna non è legata in alcun modo a una particolare istanza della classe esterna. Questo non 
avviene per le classi inteme non statiche, le cui istanze sono sempre legate a una particolare istanza 
della classe esterna; questo è il motivo per cui hanno sempre un riferimento implicito a esse. Creando 
quindi, per il nostro handler, una classe interna statica abbiamo eliminato il riferimento implicito, e 
forte, aU'activity. Ma allora come facciamo a interagire con l'attività? Per fare questo utilizziamo 
quanto imparato prima, ovvero richiediamo un riferimento nel costruttore che poi incapsuliamo 
all'interno di un oggetto di tipo weakReference. Questo è quello che avviene nel costruttore. 
All'interno del metodo handleMessage o dobbiamo però verificare l'esistenza dell' activity prima di 
interagire con essa. 

Quella descritta è una classe di cui dobbiamo creare un'istanza come fatto nel seguente codice 
della stessa classe: 

SOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_splash) ; 
mHandler = new UiHandler (this) ; 

} 

Qui onCreate ( ) è un altro metodo di callback invocato per notificare l'avvenuta creazione 
dell' activity. 

Abbiamo quindi risolto il possibile memory leak della nostra activity, ma la morale è comunque 
quella di valutare in ogni momento l'eventuale presenza di questo tipo di problemi adottando il giusto 
rimedio. 

Aggiungiamo l'evento di touch 

Fino a qui la nostra attività era comunque priva di una funzione importante, ovvero quella di 
permettere il passaggio all' activity successiva attraverso un evento di touch che comunque non 
doveva avvenire prima del tempo minimo. Per gestire questa funzionalità abbiamo realizzato la classe 

105 



TouchSpiashAotivity, che riportiamo di seguito solo per quella che è la parte di interesse: 

HOverrìde 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_splash) ; 
mHandler = new UiHandler (this ) ; 
final ImageView logoImageView = 

(ImageView) findViewById(R.id.splash_imageview) ; 
logoImageView. setOnTouchListener (new View.OnTouchListener () { 
@Override 

public boolean onTouch(View view, MotionEvent motionEvent) { 

long elapsedTime = SystemClock.uptimeMillis () - mStartTime; 
if (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 
mlsDone = true; 
goAhead ( ) ; 

} 

return false; 

} 

}); 

} 

Come possiamo notare abbiamo deciso di rendere sensibile al tocco solamente il componente 
imageview di visualizzazione dell'immagine. Per farlo abbiamo avuto la necessità di creare 
un'implementazione dell'interfaccia OnTouchLìs tener e quindi registrarla alla sorgente dell'evento, che 
nel nostro caso è appunto l'oggetto di tipo imageview, di cui però serviva il riferimento. Per questo 
motivo abbiamo utilizzato uno dei metodi più importanti ereditati dalla classe Activityl 

public View findViewByld (int id) 

il quale permette appunto di ottenere il riferimento di una specifica view conoscendone Pid. 
Questo è il motivo principale per cui nel layout abbiamo deciso di dare un identificatore al nostro 
componente di visualizzazione dell'immagine di splash nel documento di layout activity_splash . xml'. 

<ImageView 

android: layout_width=" @dimen/ splash_size" 
android: layout_height="@dimen/ splash_size" 
android: id="@+id/ splash_imageview" 

android : src=" @drawable/ ic_launcher " 
android: layout_gravity=" center " /> 

Si tratta di un metodo che ritorna un oggetto di tipo view, una classe che generalizza tutti i 
componenti visuali. Per assegnare il riferimento ottenuto a una variabile di tipo ImageView abbiamo 
dovuto eseguire un'operazione di cast. 

NOTA 

In realtà l'evento è comunque della classe view per cui tale cast non sarebbe stato necessario. A 
tale proposito ho realizzato una piccolissima libreria che, grazie a una caratteristica presente anche 
in Java che si chiama inferenza, permette di eliminare le operazioni di cast spesso fastidiose. Tale 

libreria si può trovare all'indirizzo htt P s://code . google . com/p/ android-ui-ìnference/. Per motivi didattici non 
ne faremo comunque uso. 

All'interno dell'oggetto di tipo onTouchListener non facciamo altro che controllare che sia passato 
il tempo sufficiente e quindi gestire il passaggio all'attività successiva nel modo consueto. Un'ultima 
considerazione riguarda coloro che sono abituati a sviluppare in ambito Java Standard Edition 
(JSE), dove le sorgenti permettono l'aggiunta di un numero teoricamente illimitato dilistener 
attraverso i metodi del tipo addxxListener ( ) . In ambiente mobile i metodi add sono sostituiti con i 
metodi set, che di fatto limitano a uno il numero di listener. 

La gestione dello stato 
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A questo punto la nostra attività di splash sembrerebbe conclusa se non fosse per un altro 
importante problema (che vedremo anche in relazione alla gestione dei fragment nel Capitolo 4). 
Invitiamo quindi il lettore ad avviare l'applicazione e, dopo un breve periodo di tempo, a ruotare il 
dispositivo dalla posizione portrait a quella landscape. In ambiente Android, un'operazione di 
questo tipo viene percepita come una variazione delle configurazioni allo stesso tipo di una modifica 
della lingua impostata, e provocano il riavvio dell'attività correntemente visualizzata. È come se la 
nostra splash ripartisse con il problema di un riavvio di quello che abbiamo chiamato trigger. Ogni 
volta che si ruota il dispositivo si ha il reset del tempo iniziale e quindi potremmo anche riuscire a non 
far scattare mai (a meno di non toccare il display) la transizione alla schermata successiva. Quello che 
vogliamo ottenere è quindi un modo per salvare lo stato che l'attività aveva al momento del riavvio 
per poterlo poi ripristinare successivamente come se nulla fosse successo. Ma cosa si intende per 
stato? Come ci insegna la teoria relativa alla programmazione object-oriented lo stato di un oggetto è 
rappresentato dall'insieme dei valori dei suoi attributi Nel caso della nostra attività stiamo parlando 
delle variabili che abbiamo chiamato mstartTime e misDone. Come accennato in precedenza e come 
vedremo nel dettaglio nel paragrafo successivo, ciascuna attività è soggetta a un ciclo di vita che il 
sistema notifica ai componenti attraverso l'invocazione di alcuni metodi di callback. A tale proposito 
abbiamo già intravisto i metodi oncreate ( ) e onstart ( ) . Conoscendo la natura del problema 
precedente, il sistema ci mette a disposizione il metodo |>nsaveinstance(), che viene invocato prima 
dell'eliminazione dell' activity nello scenario descritto in precedenza. Noi abbiamo implementato tale 
metodo, nella classe stateSpiashActivity, nel seguente modo: 

private static final String I S_DONE_KE Y = 

"uk . co . massimocarli . android. ugno . key . I S_DONE_KEY " ; 

private static final String START_TIME_KEY = 

"uk . co .massimocarli . android. ugho . key . START_TIME_KEY" ; 

@Override 

protected void onSavelnstanceState (Bundle outstate) { 
super . onSavelnstanceState (outstate) ; 
outstate. putBoolean(IS_DONE_KEY, misDone) ; 
outstate . putLong (START_TIME_KEY, mStartTime) ; 
} 

Notiamo come il parametro ottenuto sia un oggetto di tipo Bundie, che non è altro che un 
contenitore nel quale salvare le informazioni per poi ritrovarle successivamente. Utilizzeremo spesso 
questo oggetto anche in futuro; per il momento pensiamo a un oggetto con una serie di metodi del tipo 
putxxx ( ) , che ci permettono di associare delle informazioni a delle chiavi che abbiamo definito 
attraverso delle classiche costanti statiche. Ma dove vengono poi ripristinate queste informazioni? 
Esse si ottengono in fase di riavvio in due posizioni distinte, che nel nostro caso specifico sono molto 
utili La prima è proprio all'interno del metodo oncreate o : 

SOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_splash) ; 
if (savedlnstanceState != nuli) { 

this .mStartTime = savedlnstanceState . getLong (START_TIME_KEY) ; 

} 

mHandler = new UiHandler (this ) ; 

final ImageView logoImageView = (ImageVìew) f indViewByld (R. id. splash_imageview) ; 
logoImageView . setOnTouchListener (new View . OnTouchListener ( ) { 
SOverride 

public boolean onTouch (View view, MotionEvent motionEvent) { 
Log . d (TAG_LOG, "ImageView touched ! ! " ) ; 

long elapsedTime = SystemClock . uptimeMillis ( ) - mStartTime; 
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if (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 
mlsDone = true; 
goAhead ( ) ; 

} 

return false; 

} 

}) ; 

} 

Come possiamo notare nella parte evidenziata, il metodo oncreate ( ) ha proprio un parametro di 
tipo Bundie, il quale non è nuli solamente nel caso in cui si sia in una fase di ripristino. Ecco il motivo 
del test sul parametro savedinstancestate prima della valorizzazione della variabile mstartTime. 
Abbiamo dovuto leggere qui questa informazione altrimenti la stessa sarebbe stata resettata nel 
metodo onstart ( ) , che ora ha anch'esso un test per verificare che la variabile mstartTime non sia 
stata già valorizzata nel metodo onstart ( ) come appena descritto: 

private long mstartTime = -IL; 

@Override 

protected void onStartO { 
super . onStart () ; 
if (mstartTime == -IL) { 

mstartTime = SystemClock.uptimeMillis () ; 

} 

final Message goAheadMessage = mHandler . obtainMessage (GO_AHEAD_WHAT) ; 
mHandler . sendMessageAtTime (goAheadMessage, mstartTime + MAX_WAIT_INTERVAL) ; 

} 

Il secondo punto di ripristino è invece all'interno del metodo onRestoreinstancestate o , che nel 
nostro caso è stato implementato nel seguente modo: 

@Override 

protected void onRestorelnstanceState (Bundle savedlnstanceState) { 
super . onRestorelnstanceState (savedlnstanceState) ; 
this.mlsDone = savedlnstanceState . getBoolean (IS_DONE_KEY) ; 

} 

e che si preoccupa solamente del ripristino della variabile misDone. 

Siamo finalmente giunti a una versione più che affidabile della nostra splash. Abbiamo visto quanti 
principi e quanti problemi si presentino nella realizzazione di un componente che in teoria doveva 
essere molto semplice. Abbiamo cercato di spiegare per quanto possibile principi che comunque 
riprenderemo in maggior dettaglio nei capitoli successivi. Prima di proseguire vediamo però imo 
strumento fondamentale che non abbiamo fino a qui riportato, ovvero quello per la gestione dei 
messaggi di log. 

Logging e ADB 

Confrontando il codice nel progetto e quello che abbiamo riportato qui nel testo, il lettore noterà la 
presenza di ima serie di istruzioni del tipo 

Log . w ( TAG_LOG, "Messaggio di log..."); 

Si tratta appunto dell'utilizzo della classe Log, che dispone di un certo insieme di metodi statici per 
la visualizzazione di messaggi di log associati alle classiche priorità che vanno dall'errore al verbose. 
Sono strumenti che vengono spesso utilizzati con un altro fondamentale tool che si chiama ADB 
(Android Debug Bridge). Sostanzialmente ci permette di interagire con il dispositivo e/o AVD 
attraverso una modalità client/server. Supponiamo di aver lanciato il nostro emulatore oppure di aver 
connesso un dispositivo attraverso il cavetto USB. Una prima funzione di questo tool è proprio quella 
di permettere di verificare quali siano i dispositivi accessibili Per fare questo è sufficiente eseguire la 
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seguente opzione da riga di comando (o prompt): 

adb devices 

che ritornerà in output l'elenco dei dispositivi. Nel caso dell'emulatore si otterrà un risultato simile a 
quello nella Figura 3.22. 



eoo 


UGHO — bash — 80x24 


MacBook-Pro-di-Massimo: UGHO 
List of devices attached 
emulator-5554 device 


massimocarli$ adb devices 



Figura 3.22 Visualizzazione dei dispositivi/AVD connessi. 



NOTA 

Per poter invocare tale comando da una qualunque directory è importante che la cartella ondroid- 
sdk>/platform-tools sia compresa nel path. 

In questo caso notiamo come sia disponibile l'emulatore identificato dal nome emuiator-5554. 
Utilizziamo allora il nome del dispositivo per connetterci a esso attraverso il comando 

adb -s emulator-5554 shell 

il quale ci permette di interagire con il dispositivo attraverso una shell per l'invio di alcuni dei 
comandi tipici di un sistema Linux. Digitando il comando is per la visualizzazione del contenuto del 
file system si ottiene il risultato mostrato nella Figura 3.23. 

MacBook-Pro-di-Massimo: UGHO massimocarli$ adb -s emulator-5554 shell 

root@android:/ # Is 

acct 

cache 

conf ig 

d 

data 

default. prop 

dev 

etc 

init 

init.goldf ish. re 
init. re 

init . t race. re 

Figura 3.23 File system del dispositivo. 

In realtà nel caso in cui il dispositivo connesso sia unico non è necessario specificarne 
l'identificativo. Avremo molte occasioni per approfondire questa struttura, ma per il momento ci 
concentriamo sull' utilizzo di un importante strumento per la visualizzazione del log che si chiama 
appunto Logcat. Digitando questo comando dalla shell del dispositivo 0 direttamente dal nostro 
ambiente con 

adb -s emulator-5554 logcat 

otteniamo la visualizzazione del log del dispositivo, che apparirà al lettore subito molto verbosa, 
come vediamo nella Figura 3.24. 
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BOP nr.nn _ a db- 12' "™ £ 

E/St rictModel 743): at Jav». util.concurrent . FutureTask. runIFutureTask. java: 234) 

E/St rictModel 743) : lt Java. ut ll.concurrent .ThreadPoolExecutor. runWorkcr ( ThrcadPoolExecutor . j ava : 1888 ) 
E/StrictHode( 743) : at java. ut ll.concurrent .ThreadPoolExecutor$Worker. runl ThreadPoolExecutor. Java: 573) 
t/St rictModel 743): at Java. lang.Thread. runIThread. Java:856) 

W/Act ivityManagerl 297): Unbind failed: could not find connection for android. os.BinderProxy@41S61c98 
I/ActivltyManager( 297): START u8 {act=androld. intent. action. MAIN cat= [androld. lntent .category. LAUNCHER] f 19=8x18288888 
cfnp=com. android. speechrecorder/.SpeechRecorderActivity} from pid 682 
W/WindowManagerl 297): Failure taklng screenshot for (328x546) to layer 21885 

I/ActlvityHanager( 297): Start proc com.android.speechrecorder for activity cor». android. speechrecorder/.SpeechRecorderAc 
tlvity: pid=3896 uid=18836 gids={58036, 1828} 

E/SurfaceFlinger( 37): ro. sf . lcd_density must be defined as a bulld property 
I/PackageManager( 297): Runnlng dexopt on: com.android.speechrecorder 
D/dalvikvm( 3989): OexOpt: load 33ms, verify+opt 78ms, 217988 bytes 
E/Trace ( 3896): error opening trace file: No such file or directory (2) 

DVdalvikvmt 297): GC_CONCURRENT freed 361K, 68% free 5118K/1266BK, paused 8ms+86ms, total 458ms 
0/dalvikvm( 3896): GC_CONCURRENT freed 55K, 7% free 2813K/2996K, paused 4ms+18ms, total 51ms 
E/SurfaceFlingerl 37): ro. sf . lcd_density must be defined as a build property 
D/gralloc_goldf ish( 3896): Emulator without GPU emulation detected. 

I/ActivitvManaoerl 297): Disolaved coni. android. soeechrecorder/ . SoeechRecorderAct ivitv: ♦ls753ms 

Figura 3.24 Visualizzazione del log dell'emulatore. 

Possiamo notare come si susseguano in modo veloce informazioni relative alla nostra applicazione 
ma anche ad applicazioni della piattaforma o di sistema. Serve quindi un meccanismo che ci permetta 
da un lato di generare dei messaggi di log e dall'altro di poterli selezionare e individuare all'interno del 
logcat. 

Come detto, per quello che riguarda la generazione del log, Android fornisce la classe Log, che ci 
consente di generare messaggi di vario livello in modo molto semplice. Per descriverne il 
funzionamento è sufficiente considerare le relative istruzioni nella nostra classe di splash nella versione 
più completa, trovando delle istruzioni come quelle evidenziate qui di seguito: 

public class StateSplashActivity extends Activity { 

private static final String TAG_LOG = StateSplashActivity . class . getName () ; 

@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_splash) ; 
if (savedlnstanceState != nuli) { 

this .mStartTime = savedlnstanceState . getLong (START_TIME_KEY) ; 

} 

mHandler = new UiHandler (this ) ; 

final ImageVìew logoImageView = (ImageView) f indViewByld (R. id. splash_imageview) ; 
logoImageView . setOnTouchListener (new View . OnTouchListener ( ) { 
@Override 

public boolean onTouch (View view, MotionEvent motionEvent) { 
Log . d ( TAG_LOG , " ImageView touched ! ! " ) ; 

long elapsedTime = SystemClock . uptimeMillis ( ) - mStartTime; 
if (elapsedTime >= MIN_WAIT_INTERVAL && ImlsDone) { 

mlsDone = true; 

goAhead ( ) ; 
} else { 

Log . d (TAG_LOG, "Too much early!"); 

} 

return false; 

} 

}) ; 

} 

} 

A ciascun messaggio di log viene associato un tag, ovvero m'etichetta che ci permetterà di 
individuarlo all'interno del logcat. Nel nostro caso abbiamo definito una costante di nome appunto 
tag_log, che abbiamo utilizzato poi come primo parametro, mentre il secondo contiene effettivamente 
il messaggio da visualizzare. Come detto i messaggi di log sono moltissimi per cui serve un modo per 
riconoscere i propri. A tale scopo, nella parte bassa dell' IDE esiste un pulsante Android, che 
(associato allo shortcut corrispondente al tasto 5) permette la visualizzazione di una serie di strumenti 
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utili in fase di esecuzione delle applicazioni Selezionando il pulsante il lettore vedrà comparire 
un'interfaccia come quella nella Figura 3.25. 
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Figura 3.25 Strumenti per la gestione dei log. 

Nella parte sinistra vi è un menu a tendina che ci permette di selezionare il particolare dispositivo o 
AVD di cui è possibile osservare l'elenco dei processi attivi. Nella parte destra possiamo invece 
vedere il log vero e proprio, che inizialmente fa riferimento a tutte le applicazioni installate. Innanzitutto 
notiamo come il log abbia un colore diverso a seconda della sua gravità. Tra le informazioni 
visualizzare per ciascun log troviamo le seguenti: 

• livello; 

• timestamp dell'istanze in cui è stato generato; 

• identificatore del processo (PID); 

• identificatore del thread (TID); 

• nome dell'applicazione; 

• valore del tag; 

• testo. 

In occasione dell'esecuzione di un'applicazione, si ha la creazione automatica di un filtro associato 
nella parte sinistra. Nella parte a destra si possono configurare dei filtri in base ai criteri visualizzati 
nella Figura 3.26, selezionabili a seconda della necessità. 

Come vedremo nel prossimo paragrafo, si tratta di uno strumento di fondamentale importanza 
soprattutto in fase ditesting e debugging della nostra applicazione. 

Un'ultima considerazione in questo senso riguarda la possibilità di disabilitare tale funzionalità nelle 
applicazioni di release. In realtà non c'è nulla di preciso al riguardo, per cui dovrebbe essere 
responsabilità dello sviluppatore abilitare o meno questa funzionalità. 
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Figura 3.26 Creazione dei filtri per Logcat. 

A tale proposito l'ambiente genera in modo automatico, insieme alla classe r, anche la classe di 

nome BuildConf igl 



public final class BuildConfig { 

public final statìc boolean DEBUG 



true; 



la quale definisce la costante debug, che viene valorizzata a true nel caso in cui l'applicazione 
venga firmata con il certificato di debug e a false se firmata con un certificato di release. Ecco che 
ogni riferimento a messaggi di log dovrebbe avvenire attraverso istruzioni del tipo: 



ìf (BuildConfig. DEBUG) { 

Log . w (TAG_LOG, "My Log message"); 

} 



che sicuramente non sono di certo piacevoli Per questo motivo nella maggior parte dei casi è 
sufficiente configurare in modo opportuno il file di configurazione di ProGuard, che al momento in cui 
scrivo non è ancora stato integrato nell'IDE, uno strumento che permette sostanzialmente di offuscare 
il codice proteggendolo da eventuali decompilazioni. E un tool che comunque non tratteremo. 



Il ciclo di vita di un'activity 

Finora abbiamo fatto riferimento alle activity come a particolari componenti che rappresentano le 
schermate delle nostre applicazioni. In realtà il concetto di componente presuppone, oltre alle 
caratteristiche di modularità e riutilizzabilità, anche l'esistenza di un contenitore che in qualche modo 
ne gestisca il ciclo di vita. Il container ha quindi il compito di creare, usare e distruggere i componenti 
al suo interno. Lo stesso concetto vale per Android in quanto le activity, e come vedremo meglio 
anche iservice, sono componenti perfettamente integrati nella piattaforma. Ciascun oggetto dispone di 
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un meccanismo che permette la notifica, da parte dell'ambiente, di ogni cambio di stato in modo che il 
componente stesso possa eseguire delle operazioni di sua convenienza in corrispondenza degli stessi 
eventi 

Per poter creare delle activity che utilizzano le risorse del sistema in modo efficiente è necessario 
conoscerne il ciclo di vita, che abbiamo riassunto nella Figura 3.27 e che descriviamo nel dettaglio 
aiutandoci con una versione semplificata dell'attività di splash descritta dalla classe 
LifecycieSpiashActivity. Si tratta della stessa classe TouchSplashActivity nella quale abbiamo 
aggiunto una serie di messaggi di log e abilitato il passaggio all'attività successiva solo a seguito di un 
evento di touch Per verificare il comportamento dopo la pressione del pulsante Back abbiamo poi 
eliminato l'invocazione del metodo finish o . Questo ci permette di decidere quando passare 
all'attività successiva al fine di studiarne appunto il ciclo di vita. 
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onResume() 
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onRestartQ 
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onPause() 
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onStopQ 
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priorità più alta 
necessitano di 
memoria 



Figura 3.27 II ciclo di vita di un'activity. 

Quando viene richiesta l'esecuzione di un'activity, il sistema crea un'istanza della corrispondente 
classe e la porta nello stato started. Si tratta però di un'attività ancora inutilizzabile in quanto priva di 
molte impostazioni, come per esempio quello che sarà il layout. Una volta creata l'istanza, il sistema 
invoca il metodo 

protected void onCreate (Bundle savedlnstanceState) 

all'interno del quale metteremo tutte quelle operazioni che vengono eseguite una sola volta, ovvero 
l'impostazione del layout e il salvataggio dei riferimenti dei relativi componenti. Tra tutti i metodi di 
callback, questo è l'unico con un parametro di tipo Bundie che, come visto in precedenza, 
rappresenta un contenitore di informazioni resistente alle variazioni delle configurazioni o 
dell'orientamento. Se l'attività è avviata per la prima volta il parametro assume il valore nuli. 

Il passo successivo consiste nella visualizzazione del layout, che viene notificato attraverso 
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l'invocazione del metodo 

protected void onStartO 

È bene sottolineare il fatto che nel metodo onstart ( ) vengono implementate tutte quelle 
funzionalità che sono legate alla visualizzazione ma non all'interazione con gli utenti 
Nell'implementazione di questo metodo vengono spesso registrati gli eventuali listener 
(BroadcastReceiver) su intent di broadcast o comunque operazioni legate a ciò che si vede. 
L'effettiva possibilità di interazione viene invece notificata attraverso l'invocazione del metodo 

protected void onResume() 

In questo metodo vengono quindi implementate tutte quelle funzioni che sono legate all'effettivo uso 
da parte dell'utente, come per esempio l'accesso a risorse come la video-camera, suoni o animazioni. 

A questo punto il lettore è già in grado di fare un test eseguendo l'applicazione dopo aver indicato 
nel documento AndroidManif est . xml la classe LifecycieSpiashActivity come quella principale. 
Dopo aver creato il corrispondente filtro basato sul valore della costante tag_log otterremo il 
seguente risultato, dove activity_a indica il fatto che siamo nella prima attività. E bene inoltre 
precisare come, per convenienza, siano state eliminate le informazioni relative al valore del tag e al 
timestamp del messaggio di log: 

ACTIVITY_A -> ON CREATE 
ACTIVITY_A -> ON START 
ACTIVITY_A -> ON RESUMÉ 

A questo punto l'attività è nello stato running e l'utente è in grado di interagire con essa: nel nostro 
caso abbiamo deciso di passare alla seconda attività attraverso un evento di touch. 
NOTA 

È importante non ruotare il dispositivo durante i test di questo paragrafo in quanto, come vedremo 
tra poco, comporterebbe il riavvio dell'activity attiva in quel momento. 

Prima di toccare il display vogliamo vedere che cosa succede se si preme il pulsante Back e quindi 
si esce dall'applicazione. Anche in questo caso non si ha un passaggio unico ma il tutto si svolge in tre 
step differenti II primo consiste nel rendere non più interattiva l'activity, il che viene notificato 
attraverso l'invocazione del metodo: 

protected void onPause () 

Si tratta del metodo simmetrico rispetto a onResume ( ) , che dovrebbe quindi eliminare le eventuali 
risorse in esso allocate. 

Quando un'attività non viene più visualizzata, completamente o in parte, nel display viene invocato 
il metodo 

protected void onStopO 

che rappresenta quindi il metodo simmetrico rispetto a onstart ( ) . Nel caso in cui l'attività venisse 
eliminata, per la pressione del pulsante Back, si avrebbe infine l'invocazione del metodo 

protected void onDestroyO 

Per dimostrare quando descritto eseguiamo ancora la nostra applicazione per poi selezionare il 
pulsante Back per uscire da essa: 

ACTIVITY_A -> ON CREATE 

ACTIVITY_A -> ON START 

ACTIVITY_A -> ON RESUMÉ 

ACTIVITY_A -> ON PAUSE 

ACTIVITY_A -> ON STOP 

ACTIVITY_A -> ON DESTROY 

Quello descritto è il ciclo di vita di una singola attività ma nella maggior parte dei casi le attività 
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interagiscono con altre che le stesse attivano attraverso il lancio di un intent. Per capire che cosa 
succede in questa situazione abbiamo quindi aggiunto gli stessi messaggi di log anche alla classe 
First Acce ssActivity caratterizzandoli con il valore activity_b per poterli distinguere dai 
precedenti. 
NOTA 

Per avere i messaggi relativi alle due attività all'interno dello stesso log abbiamo utilizzato uno 
stesso valore per la costante tag_log, che nel caso specifico è lifecycle. 

Dopo aver visualizzato la prima schermata tocchiamo quindi il display e passiamo alla successiva 
ottenendo il seguente log, nel quale abbiamo evidenziato i messaggi successivi all'evento di touch: 

ACTIVITY_A -> ON CREATE 
ACTIVITY_A -> ON START 
ACTIVITY_A -> ON RESUMÉ 
ACTIVITY_A -> ON PAUSE 
ACTIVITY_B -> ON CREATE 
ACTIVITY_B -> ON START 
ACTIVITY_B -> ON RESUMÉ 
ACTIVITY_A -> ON STOP 

È importante notare come il primo metodo invocato sia onPause ( ) sulla prima attività per fare in 
modo che l'utente non possa più interagire con essa. A questo punto Andro id, che intende fare di 
tutto per aumentare la responsiveness, renderà attiva la seconda activity preoccupandosi, solo 
quando questa è nello stato running, di portare la prima nello stato di stop. A questo punto la 
pressione del pulsante Back poterà all'invocazione dei seguenti metodi; 

ACTIVITY_B -> ON PAUSE 

ACTIVITY_A -> ON RESTART 

ACTIVITY_A -> ON START 

ACTIVITY_A -> ON RESUMÉ 

ACTIVITY_B -> ON STOP 

ACTIVITY_B -> ON DESTROY 

ACTIVITY_A -> ON PAUSE 

ACTIVITY_A -> ON STOP 

ACTIVITY_A -> ON DESTROY 

Anche in questo caso Android si preoccupa di mettere la seconda attività nello stato pause per poi 
riattivare quella che prima era in background con l'aggiunta dell'invocazione del metodo 

protected void onRestartO 

La prima attività viene riportata in running e quindi ci si preoccupa di eliminare la seconda 
invocando su di essa i metodi onStopO e onDestroy ( ) . Il metodo onRestart ( ) è stato aggiunto come 
alternativa al metodo oncreate ( ) , che non viene eseguito in questi casi. Esso permette di ripristinare, 
per esempio, oggetti che erano stati creati nell'oncreate () ma poi erano stati disabilitati nell'onstop ( ) . 
Il caso tipico, come vedremo nel Capitolo 8 dedicati alla gestione dei dati, è quello di un cursore. 

NOTA 

La conoscenza del ciclo di vita delle activity e di altri componenti è fondamentale per un utilizzo 
ottimale delle risorse offerte dalla piattaforma come, per esempio, quelle che permettono l'accesso 
alla base dati. 

Nella Figura 3.27 abbiamo evidenziato anche un altro possibile flusso attraverso una nota associata 
al numero 4. Si tratta del caso in cui un'attività viene ripristinata a partire dallo stato pause ovvero 
quando, non essendo attiva, viene comunque visualizzata. È il caso in cui la seconda attività viene 
lanciata con un tema di tipo Dialog, che quindi non occupa tutto lo spazio disponibile. Per verificare 
quelpath è sufficiente definire la seconda attività nel seguente modo: 

Octivity 

android: name=" . FirstAccessActivity " 

android : theme=" Sandroid : style/Theme . Dialog" > 
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</aotivity> 

Lasciamo al lettore la verifica di come, ripetendo le azioni precedenti, il metodo onstop o non 
venga invocato sulla prima attività e come il metodo onRestart ( ) non venga invocato in 
corrispondenza della pressione del pulsante Back. 

Nel diagramma precedente abbiamo visto che un'activity si trova nello stato di paused o stopped a 
seconda che sia parzialmente visibile o completamente in background. Nel caso in cui la piattaforma 
ne avesse la necessità è possibile che le activity vengano terminate perché di priorità inferiore a quella 
che è l'attività che interagisce in quel momento con l'utente. Si tratta delpathche abbiamo indicato 
con il numero 6. In questo caso Android non ci fornisce alcun meccanismo di notifica ma permette di 
rendere comunque il tutto trasparente riattivando le activity eliminate qualora nuovamente richieste. 
Questo può comunque rappresentare un problema di cui però conosciamo già in parte la soluzione. 

Per dimostrare quanto affermato facciamo un esperimento che necessita dell'utilizzo dell'emulatore 
o comunque di un dispositivo con utente di root nel quale eseguiamo l'app Reazione precedente con 
una piccola modifica nel documento di configurazione AndroidManif est .xml. In corrispondenza 
dell'attività di destinazione utilizziamo l'attributo android :process per assegnare un valore che nel 
nostro caso è :other_ P rocess. Sappiamo che tutti i componenti di un'applicazione vengono eseguiti 
all'interno di uno stesso processo a meno che non si specifichi, appunto attraverso l'attributo 
android :process, unprocesso diverso che le convenzioni vogliono inizi con i due punti (:): 

<activity android: name=" . FirstAccessActivity " android :process=" : other__process"> 

</ activity> 

NOTA 

È bene fare attenzione qualora vi fossero più dispositivi/emulatori attivi. In quel caso sarà necessario 
specificare a quale di essi connettersi attraverso l'opzione - s , come descritto nella documentazione 

Ufficiale all'indiriZZO http://developer.android.com/tools/help/adb.html. 

Ora eseguiamo l'applicazione e utilizziamo il tool adb (Android Debug Bridge) attraverso 
l'esecuzione del seguente comando: 

adb shell che ci permette di accedere al dispositivo con un' interfaccia a riga di comando. Come 
detto, eseguiamo la nostra applicazione e selezioniamo il pulsante passando dalla visualizzazione 
dell'attività A alla visualizzazione dell'attività B. Una volta entrati all'interno della shell del dispositivo 
eseguiamo il seguente comando per la visualizzazione dei processi attivi 



ps 

ottenendo un output simile al seguente 
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Nella parte evidenziata notiamo i due processi associati alle due attività. È bene ricordare, e ne 
lasciamo la verifica al lettore, che nel caso standard all'applicazione sarebbe stato associato un solo 
processo all'interno nel quale vi erano entrambe le attività. Questo stratagemma ci permette di 
compiere un' operazione fondamentale, ovvero quella di terminare il processo associato alla prima 
attività quando quella attiva è in effetti la seconda. Per fare questo utilizziamo il comando 
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kill -9 5190 

dove 5190 è ilPID del processo da eliminare. Ripetendo l'esecuzione del comando ps il lettore 
potrà verificare l'effettiva eliminazione del processo ma constatare anche che l'applicazione nonne ha 
risentito in alcun modo. Altro aspetto fondamentale è che non vi è stata alcuna notifica, attraverso 
metodi di callback, di quanto successo. Abbiamo, di latto, eseguito una possibile operazione che il 
sistema può decidere di compiere quando servono risorse. Fortunatamente il sistema si preoccuperà 
anche di ripristinare l'attività precedente nel caso in cui premessimo il pulsante Back. Questo è 
làcilmente dimostrabile osservando che, alla pressione del pulsante Back, la prima attività viene 
nuovamente visualizzata e il relativo processo va nuovamente in esecuzione. 

Concludiamo il paragrafo con un'osservazione importante sui metodi di callback: in ognuno di essi 
ci deve obbligatoriamente essere l'invocazione, attraverso il riferimento super, all'implementazione 
nella superclasse. In caso contrario si ha il sollevamento di un'eccezione. Questo accorgimento si 
rende necessario in quanto anche la classe Activity esegue particolari operazioni "di servizio" in 
corrispondenza degli stessi metodi di callback. 

Attività di gestione della prima esecuzione 

Prima di proseguire con il nostro sviluppo facciamo un breve punto della situazione. Con molta 
fatica e tanti concetti, siamo giunti alla realizzazione di una schermata di splash molto robusta che 
permette la visualizzazione di un'immagine, sebbene provvisoria, e di passare quindi a una schermata 
descritta dall'attività che abbiamo chiamato Fir stAocessActivity. Il compito di questa attività sarà 
quello di gestire la prima esecuzione e chiedere all'utente se intende accedere in modo anonimo, se si 
vuole registrare o se vuole eseguire il login. 

NOTA 

In questa prima fase passiamo direttamente dalla splash a questa attività senza verificare, come 
faremo invece successivamente, se l'utente è già registrato o loggato. Implementeremo questa 
logica quando creeremo il nostro modello di dati per l'utente. 

Come prima ci accingiamo a realizzare il layout che conterrà semplicemente tre oggetti di tipo 
Button e sarà descritto dal seguente documento XML di nome activìty_menu.xml nella cartella di 
layout: 

<LinearLayout xmlns : android="http : / /schemas . android. oom/ apk/res/ android" 
xmlns : tools="http : / / schemas . android. com/tools" 
android : layout_width="match_jparent " 
android : layout_height="match_parent " 

android : paddingLef t="@dimen/ activity_horizontal_margin" 
android : paddingRight=" Sdimen/ activity_horizontal_margin" 
android : paddingTop=" @dimen/ activity_vertical_margin" 
android : paddingBottom=" @dimen/activity_vertical_margin" 
tools : context=" . FirstAccessActivity" 
android: orientation="vertical"> 

<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: text="@string/new_data_button_label" 
android : id= " @+id/ insert_new_data_button " / > 

<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: text="@string/old_data_button_label" 
android : id= " @ +id/ view_old_data_butt on " / > 
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<Button 

android : layout_width=" f ill_parent " 

android: layout_height="wrap_content " 

android: text="@string/remote_data_button_label" 

android : id= " @+id/ view_remote_data_button " / > 

</ Linear Layout > 

di cui abbiamo ancora evidenziato le parti importanti. Innanzitutto notiamo come i Button siamo 
contenuti all'interno di un LinearLayout con orientamento verticale. Questo significa che i diversi 
componenti verranno disposti uno sotto l'altro. Interessante è poi l'utilizzo dell'attributo 
toois:context valorizzato conilnome dell'attività J'irstAccessActivity. Questa è un'informazione 
che in realtà non viene usata dall'ambiente Android ma dall'IDE. Sappiamo infatti che un layout può 
essere assegnato a più attività ma anche che, nel file AndroidManif est . xml, possiamo assegnare a 
esse temi diversi L'IDE ha quindi bisogno di sapere quali siano i temi da applicare al particolare 
layout in preview e questo attributo è una valida soluzione. Di seguito abbiamo quindi i diversi Button 
che notiamo essere identificati da opportuni attributi del tipo android : id. Come vedremo tra poco, 
questi ci permetteranno di identificare ciascun pulsante e quindi ottenerne un riferimento da codice 
Java. Notiamo poi l'utilizzo di un tipo di risorse di fondamentale importanza, ovvero quelle di tipo 
String che, nel caso specifico, ci consentono di specificare le diverse etichette. L'uso di questo tipo di 
risorse ci permette infatti di creare delle applicazioni perfettamente internazionalizzate (I18N) senza 
alcuno sforzo a livello di codice ma giocando, come sappiamo, con i qualificatori. Il risultato del 
layout è mostrato nella Figura 3.28. 



UGHO 




Anonymous 



Register 



Login 



Figura 3.28 Layout relativo all'attività FirstAccessActivity. 

Non è molto accattivante ma per il momento va più che bene. Se osserviamo il diagramma della 
nostra applicazione della Figura 3.1, notiamo come anche il layout dell'attività di destinazione della 
scelta di accesso anonimo non è molto diverso per cui realizziamo un layout simile contenuto 
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all'interno del file activity_menu . xml ; lo descriveremo successivamente insieme alla corrispondente 
attività che sarà descritta dalla classe MainActivity creata per poter avere un' attività di destinazione 
a seguito della selezione del primo pulsante. Il codice Java della classe FirstAccessActivity dovrà 
gestire i comportamenti associati ai tre pulsanti Per tare questo abbiamo scritto il seguente codice: 

HOverrìde 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 

final Button anonymousButton = (Button) f indViewByld (R. id. anonymous_button) ; 
anonymousButton . setOnClickListener (new View . OnClickListener ( ) { 
QOverride 

public void onClick (View view) { 
enterAsAnonymous ( ) ; 

} 

}); 

final Button registrationButton = (Button) f indViewByld (R. id. register_button) ; 
registrationButton . setOnClickListener (new View . OnClickListener ( ) { 
QOverride 

public void onClick (View view) { 
doRegistration () ; 

} 

}); 

final Button loginButton = (Button) f indViewByld (R. id. login_button) ; 
loginButton . setOnClickListener (new View . OnClickListener ( ) { 
QOverride 

public void onClick (View view) { 
doLogin ( ) ; 

} 

}); 

} 

Notiamo come il metodo onCreate o consista sostanzialmente nell' ottenere un riferimento ai 
Button a cui poi registrare deilistener descritti da classi anonime che implementano l'interfaccia 
OnClickListener. In corrispondenza della selezione del relativo pulsante si ha quindi l'invocazione di 
altrettanti metodi di utilità. In corrispondenza della selezione del pulsante associato all'ingresso 
anonimo dell'applicazione non facciamo altro che invocare il seguente metodo: 

private void enterAsAnonymous ( ) { 

Log . d (TAG_LOG, "Anonymous access"); 

final Intent anonymous Intent = new Intent (this, MenuActivity . class) ; 
startActivity (anonymouslntent) ; 

} 

che ora non presenta novità. Non si fa altro che utilizzare un intent esplicito per arrivare all'attività 
con il menu principale che abbiamo chiamato MenuActivity e che esamineremo più avanti 

Definizione del modello 

Nel paragrafo precedente abbiamo accennato al concetto di utente, il quale può essere anonimo 
oppure si può autenticare al sistema attraverso un'operazione di login o di registrazione. In ogni caso 
esiste un profilo utente le cui informazioni devono essere incapsulate all'interno di un oggetto che 
descriviamo attraverso la classe UserModel che andiamo a realizzare all'interno del sottopackage 

model. 
NOTA 

Sempre nell'ottica di un miglioramento progressivo dell'applicazione, il nostro modello sarà 
inizialmente molto semplice e non integrato con quelli che sono gli appositi strumenti della 
piattaforma, che vedremo invece nel Capitolo 12. 

Si tratta di una classe che contiene diverse proprietà relative alle informazioni che chiederemo in 
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fase di registrazione. Nel caso di accesso anonimo, il nostro utente dovrà inserire le informazioni sulla 
sua data di nascita, che quindi diventa l'unica informazione completamente obbligatoria. Questa 
caratteristica del nostro modello si rappresenta con un pattern ben preciso che utilizza quello che si 
chiama static factory method unito alla possibilità di eseguire un chaining. Per capire di cosa si tratta 
riportiamo il codice della classe UserMode i. Come dicevamo l'unica informazione obbligatoria per la 
nostra applicazione è la data di nascita. Questo significa che non deve essere possibile creare 
un'istanza diuserModei senza specificare questa informazione. A livello di codice questo si esprime 
nel seguente modo: 

public class UserModel { 

private long mBirthDate; 

private UserModel (final long birthDate) { 
this . mBirthDate = birthDate; 

} 

public static UserModel create (final long birthDate) { 

final UserModel userModel = new UserModel (birthDate) ; 
return userModel; 

} 



Intanto abbiamo creato un unico costruttore con visibilità private impedendo di fatto la creazione 
di istanze di userModel di fuori della classe stessa. 
NOTA 

Per la proprietà dei costruttori di invocare, come prima istruzione, il costruttore di default della 
classe padre, impostare una visibilità private equivale a impostare la classe come fimi. 

L'unico modo per creare un'istanza di UserModel è quindi il metodo static factory. Esso prevede 
come unico parametro la data di nascita come long (i classici millisecondi dal 1° gennaio 1970). Non 
possiamo quindi creare un'istanza di userModel senza passare una data di nascita come parametro. 

NOTA 

Nel caso di utilizzo del costruttore di default e quindi del metodo setBirthDateo, avremmo creato un 
oggetto che per un determinato momento avrebbe assunto uno stato non corretto e sappiamo che 
in un ambiente multithreading, oltre che per la legge di Murphy, questo potrebbe essere un 
problema. 

Un altro vantaggio non indifferente di questo semplice ma potente pattern consiste nel fatto che 
ritorna da subito un'istanza sulla quale è possibile invocare dei metodi Per intenderci, possiamo 
scrivere del codice del tipo: 

UserModel model = UserModel . create (myBirthDate) . withUsername (myUsername) 

. withEmail (myEmail ) . withLocation (myLocation) ; 

che prende appunto il nome di chaining e permette la scrittura di codice più compatto e comunque 
semplice. Si tratta della tecnica che abbiamo adottato per le proprietà facoltative come lo username, 
l'e-mail e la location, che non sono necessarie nel caso di un utente anonimo. 

NOTA 

Per il momento la location sarà rappresentata da una String ma vedremo più avanti come 

aggiungere informazioni più precise come latitudine e longitudine. 

Nel nostro modello abbiamo implementato anche i seguenti metodi, che ci permettono di sapere se 
l'utente è nello stato anonimo o se si è loggato. 

public boolean isAnonymous ( ) { 
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return TextUtils . isEmpty (this . mUsername) ; 

} 

public boolean isLoggedO { 

return ! TextUtils . isEmpty (this .mUsername) ; 

} 

Come possiamo vedere questa condizione è legata alla presenza o meno di uno username. 

La gestione del login 

In precedenza abbiamo visto come sia semplice gestire il passaggio dall'attività di prima esecuzione 
a quella del menu principale attraverso il semplice utilizzo di un intent esplicito. Per quello che riguarda 
la gestione del login vogliamo invece descrivere un altro scenario molto comune di collaborazione tra i 
componenti della piattaforma. All'inizio del capitolo abbiamo descritto l'esempio di un' applicazione 
che necessita della scelta di un contatto. Invece che implementare da zero questa funzionalità, 
Andro id ci consente di lanciare un intent per chiedere alla rubrica di permettere la selezione di un 
contatto i cui riferimenti dovranno poi essere ritornati all'oggetto che ne ha fatto richiesta. Questo 
scenario è esattamente quello che intendiamo implementare per il login Alla pressione del pulsante di 
login vogliamo visualizzare un'attività per la richiesta delle credenziali che dovrà gestire l'accesso, per 
il momento simulato, a un server e quindi notificare il risultato all'attività chiamante, che in questo caso 
è la FirstAccessActivity. Possiamo quindi scomporre questo scenario in tre fasi distinte. 

• L'invio della richiesta. 

• L'elaborazione della richiesta nel componente di destinazione. 

• Il ritomo della risposta e la relativa elaborazione. 

Il primo punto è molto semplice e prevede l'invio di un intent non attraverso il metodo 
startActivity o ma attraverso il metodo 

public voìd startActivityForResult (Intent intent, int requestCode) 

che dispone di due parametri. Il primo è appunto l' intent che descrive la richiesta, mentre il 
secondo è un identificatore del tipo della stessa che ci permette di identificarla nel momento di 
ricezione dei risultati. Nel caso in cui una stessa activity lanciasse più intent per la richiesta di 
informazioni diverse a componenti diversi, serve infatti un meccanismo che permetta di distinguere le 
varie risposte le quali, come vedremo tra poco, utilizzano lo stesso meccanismo di notifica. 

NOTA 

L'utilità di questa informazione sarà owia nel momento in cui dovremo gestire anche la registrazione 
con lo stesso meccanismo. 

Questo primo passo è stato da noi implementato nel seguente metodo della classe 
FirstAccessActivity, che viene invocata a seguito della pressione del pulsante di login: 

private static final int LOGIN_REQUEST_ID = 1; 

private void doLogin() { 

final Intent loginlntent = new Intent (LoginActivity . LOGIN_ACTION) ; 
StartActivityForResult (loginlntent, LOGIN_REQUEST_ID) ; 

} 

Notiamo come sia stato creato un intent associato all'azione login_action che abbiamo definito 
come costante nell'attività di destinazione e quindi utilizzato il metodo ItartActìvityForResuit o a 
cui abbiamo passato anche l'identificatore della richiesta definita attraverso un'altra costante. 

Il lettore si chiederà come mai utilizziamo un'action specifica quando sappiamo qual è il 
componente di destinazione. Un primo aspetto riguarda il fatto che una stessa attività, o un 
componente, potrebbe avere comportamenti diversi a seconda dell'action con cui viene invocata. Nel 
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caso del logia, per esempio, potremmo in un caso gestire l'operazione di autenticazione e in un altro 
semplicemente visualizzare lo username senza permetterne l'editing o l'inserimento della password. 
Una seconda applicazione non avrebbe a disposizione la costante LoginActivity .login_action ma 
comunque avrebbe accesso alla documentazione, e quindi potrebbe definire una propria costante. Lo 
stesso deve essere fatto nel documento AndroidManif est . xml, che non può accedere alle costanti 
definite nel codice. Nel nostro caso abbiamo infatti aggiunto la seguente definizione: 

Octivity android: name=" .LoginActivity" 

android: label="@string/login_activity_label "> 
<intent-f ilter> 

<action android: name="uk . co .massimocarli . android. ugho . action . LOGIN_ACTION"/> 
<category android : name= " android . intent . category . DEFAULT " /> 

</intent-f ilter> 
</ activity> 

A parte il nostro andare a capo nella definizione dell'action per motivi di spazio che non deve 
avvenire nel documento reale, notiamo come sia stata anche definita la category di default che è 
sempre presente negli intent lanciati nel modo da noi descritto. 

A questo punto la pressione del pulsante di login porta alla visualizzazione della corrispondente 
attività che avevamo in precedenza creato e che il lettore può comunque consultare. Si tratta di 
un'attività non molto diversa da quelle che abbiamo creato fin qui se non nella parte che ci accingiamo 
a descrivere, e che riguarda appunto l'interazione con il componente chiamante. Il suo compito sarà 
quello di raccogliere le informazioni relative a username e password, invocare il servizio di 
autenticazione e quindi ritornare l'esito alla nostra attività dipartenza, la quale deciderà cosa fare. Il 
layout dell'attività di login descritta dalla classe LoginActivity è il seguente e presenta una novità 
molto importante nella gestione delButton, che avrebbe semplificato di molto il codice anche delle 
precedenti. Osservando il relativo layout notiamo come 

<LinearLayout xmlns : android="http : / /schemas . android. com/ apk/res/ android" 
xmlns : tool s=" http : / / schemas . android. com/tools " 
android : layout_width="match__parent " 
android : layout_height="match_parent " 

android : paddingLef t="@dimen/ activity_horizontal_margin" 
android : paddingRight="@dimen/ activity_horizontal_margin" 
android : paddingTop="@dimen/ activity_vertical_margin" 
android : paddingBottom= " @dimen/activity_vertical_margin" 
tools : context=" . LoginActivity" 
android : orientation="vertical"> 

<! — Definizioni di Label ed EditText — > 

<TextView 

android: layout_width="wrap_content " 
android: layout_height="wrap_content " 

android: textAppearance=" ? android : attr/textAppearanceMedium" 
android: textColor="@color/red" 
android : visibility=" invisible " 

android: id=" @+id/ error_message_label " /> 

<Button 

android: layout_width="wrap_content " 
android: layout_height="wrap_content " 
android: text="@string/ login_button_label " 
android: id="@+id/login_button" 
android : onClick= " doLogin " 
android: layout_gravity=" center "/> 

</ Linear Layout > 

Ora abbiamo un attributo di nome android: onciick il cui valore nonè altro che il nome di un 
metodo che verrà invocato in corrispondenza dell'evento di clic. Stiamo parlando di un metodo che 
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deve essere definito nella particolare specializzazione del Context che è owner del layout e che ha un 
unico parametro di tipo view che verrà poi valorizzato con la sorgente dell'evento, che in questo caso 
sarà il Button stesso ma che potrebbe in genere essere un'altra view cliccabile. Nel nostro caso il 
metodo dovrà quindi essere descritto all'interno della classe LoginActivity che possiede e gestisce 
la gerarchia descritta dal layout. Prima di vedere come questo metodo è stato implementato facciamo 
una brevissima digressione su un tipo di risorse molto importanti che abbiamo utilizzato per la 
visualizzazione dei possibili messaggi di errore; stiamo parlando delle risorse di tipo color. Attraverso 
di esse possiamo definire dei colori nei termini delle loro componenti RGB, oltre a quella alfa relativa 
alla trasparenza (indicata con a). Le sintassi utilizzabili sono le seguenti: 

#RGB 
#ARGB 
#RRGGBB 
#AARRGGBB 

Nel nostro progetto abbiamo creato il file main/ java/res/vaiues/coiors .xml che notiamo essere 
diviso in due parti La prima contiene dei colori assoluti mentre nella seconda parte li abbiamo 
contestualizzati Questa separazione ci permetterebbe, per esempio, di definire i colori assoluti come 
risorsa di una libreria che poi utilizziamo in modo contestualizzato in più progetti diversi: 

<?xml version="l . 0" encoding="utf-8" ?> 
<resources> 

<! — Absolute colors — > 
<color name="red">#FF0000</color> 
<color name=" green ">#00FF00</ color > 
<color name="blue">#0000FF</color> 
<color name="white">#FFFFFF</ color > 
<color name="black">#000000</color> 
<color name="grey">#BBBBBB</ color > 
<color name="light_grey">#EEEEEE</ color > 
<color name="dark_grey ">#555555</ color> 

<! — Application colors — > 

<string name="error_message_color">@color/red</ string> 
</ resources> 

Una comoda novità dell'editor di layout di Android Studio consiste nella possibilità di ottenere una 
preview del colore impostato in modo da avere da subito un'idea del risultato. Questo succede sia 
nella preview del layout che utilizza questi colori sia nella visualizzazione del documento precedente, 
come possiamo vedere nella Figura 3.29. 
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<?xml version^'1.0" encoding="utf-8 n ?> 
[^<resources> 

</ — Absolute colors — > 
<color name=" red">#FF0000</color> 
<color name="green">#00FF00</color> 
<color name="blue">#0000FF</color> 
<color name="white">#FFFFFF</color> 
<color name="black">#000000</color> 
<color name="grey">#BBBBBB</color> 
<color name="light_grey">#EEEEEE</color> 
<color name="dark_grey">#555555</color> 

</ — Application colors — > 

<string name="error_message_color">@color/red</string> 
é)</resources> 



Figura 3.29 Preview delle risorse di tipo color. 

In questo caso le costanti generate saranno della classe r. color e la sintassi da utilizzare come 
riferimento ai colori nelle altre risorse del tipo @coior/white. Un'ultima osservazione riguarda il fatto 
che il riferimento a una risorsa di tipo color può essere utilizzata in ogni luogo in cui l'ambiente si 
attende una risorsa di tipo Dmwable, che vedremo essere relativa a tutto ciò che può essere 
disegnato. 

Nel nostro caso abbiamo implementato il metodo doLogin ( ) nel seguente modo che è importante 
descrivere in relazione ad altri nuovi importanti concetti: 

public void doLogin (View loginButton) { 

this .mErrorTextView. setVisibility (View. INVISIBLE) ; 

final Editable usernameEdit = mUsernameEditText . getText ( ) ; 

if (TextUtils . isEmpty (usernameEdit ) ) { 

final String usernameMandatory = getResources ( ) 

. getString (R. string.mandatory_f ield_error, "username") ; 
this .mErrorTextView. setText (usernameMandatory) ; 
this .mErrorTextView. setVisibility (View.VISIBLE) ; 
return; 

} 

final Editable passwordEdit = mPasswordEditText . getText () ; 
if (TextUtils . isEmpty (passwordEdit ) ) { 

final String passwordMandatory = getResources ( ) 

. getString (R. string. mandatory_field_error, "password" ) ; 

this .mErrorTextView. setText (passwordMandatory) ; 

this .mErrorTextView. setVisibility (View.VISIBLE) ; 

return; 

} 

final String username = usernameEdit . toString () ; 
final String password = passwordEdit . toString () ; 

final UserModel userModel = LoginService . get (). login (username, password); 
if (userModel != nuli) { 

Intent resultlntent = new Intento ; 

resultlntent . putExtra (USER_DATA_EXTRA, UserModel) ; 

setResult (RESULT_OK, resultlntent) ; 

finish () ; 
} else { 

this .mErrorTextView. setText (R. string. wrong_credential_error) ; 
this .mErrorTextView. setVisibility (View.VISIBLE) ; 
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} 

} 

La prima parte del metodo non fa altro che andare a leggere il contenuto dei campi di testo 
descritti dalle classi EditText e verificare che siano valorizzati In caso contrario visualizzeremo i 
corrispondenti messaggi di errore all'interno di una Textview di cui abbiamo ottenuto in precedenza il 
riferimento all'interno del metodo oncreate ( ) . In questa fase non abbiamo molte osservazioni da fare 
se non quella relativa alla gestione delle risorse di tipo String da codice Java attraverso una sintassi 
che ci permette diparametrizzarle. Abbiamo infatti definito la seguente risorsa aggiuntiva 

<string name="mandatory_f ield_error">The field %l$s is mandatory</string> 

che contiene un placeholder per indicare la posizione delle varie parti dinamiche. Attraverso il 
simbolo %i$s abbiamo indicato che il primo elemento dinamico (%i) è una String ($s). Attraverso la 
notazione %2$d avremmo potuto indicare invece un secondo elemento di tipo intero e così via. La 
notazione è la seguente: 

%<ord>$<type> 

dove ord è la posizione del parametro associato mentre type il corrispondente tipo. 

Torniamo alla parte fondamentale della nostra attività di login, ovvero quella che ci permette di 
ritornare il risultato al componente chiamante. Come detto in precedenza, non realizzeremo il servizio 
vero e proprio ma ci accontentiamo di una classe che implementa l'operazione di login in modo 
dummy. Per questo motivo abbiamo creato la classe loginservice con un metodo login o che 
confronta le credenziali passate con alcune costanti 

public UserModel login (final String username, final String password) { 
UserModel userModel = nuli; 

if (DUMMYUSERNAME . equalsIgnoreCase (username) && 
DUMMY_PASSWORD . equalsIgnoreCase (password) ) { 
userModel = 

UserModel . create (System. currentTimeMillis () ) . withEmail ( "dummygdaisy . com" ) ; 
} 

return userModel; 

} 

Il contratto alla base di questo metodo prevede che venga ritornato un oggetto userModel in caso 
di login valido o nuli in caso di login errato. Questo è il motivo del test nella parte conclusiva del 

metodo doLogin ( ) : 

ìf (userModel != nuli) { 

Intent resultlntent = new Intento ; 

result Intent . putExtra (USER_DATA_EXTRA, userModel ) ; 

setResult (RESULT_OK, resultlntent) ; 
finish ( ) ; 
} else { 

this .mErrorTextView. setText (R. string. wrong_credential_error) ; 
this .mErrorTextVìew. setVisibility (View.VISIBLE) ; 

} 

In caso di successo sarà sufficiente creare un intent all'interno del quale inseriremo le informazioni 
che vogliamo trasmettere come valore dintorno. Questo scenario ci permette di introdurre un'altra 
caratteristica fondamentale degli intent che si traduce nel concetto ài extra. Possiamo pensare a 
queste informazioni come a dei parametri che viaggiano insieme a un intent ma che non hanno nulla a 
che fare con quelle che sono le regole di intent resolution. Per intenderci, un componente non 
risponderà o meno a un intent per la presenza o mancanza di un suo valore extra. Per assegnare tali 
valori a un intent si utilizzano i vari overload del metodo putExtra ( ) evidenziato, sopra il quale 
prevede come primo parametro una chiave di tipo String e come secondo appunto il corrispondente 
valore. Nel nostro caso specifico abbiamo creato un intent (notiamo che non ha alcuna action 
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associata) nel quale inseriamo l'oggetto UserModel associandolo alla chiave corrispondente alla 
costante user_data_extra precedentemente definita. Gli extra potrebbero essere quanti vogliamo, 
ciascuno associato a chiavi diverse. Il passo successivo consiste nel ritornare tale intent al 
componente che aveva eseguito la richiesta. Per fare questo è necessario seguire due passi II primo 
consiste nelT impostare l'intent di ritorno attraverso il metodo setResuit o e quindi terminare Fattività 
attraverso il metodo finish ( ) . È importante specificare come il metodo setResuit ( ) non faccia di 
per se nulla sé non impostare l'intent da ritornare, che diventa poi effettivo nel momento di esecuzione 
del metodo fi nish ( ) . 

NOTA 

Se invocassimo più volte il metodo setResuit o e quindi chiamassimo il metodo finish o, il valore 
ritornato sarebbe l'ultimo impostato. 

Il primo parametro del metodo setResuit o si chiama resuitcode, e consente di trasmettere 
l'esito della richiesta. Esso può assumere i valori 

Activity . RESULT_OK 
Activity . RESULT_CANCELED 

oppure valori personalizzati che dovranno comunque essere maggiori o uguali al valore indicato 
dalla costante 

Activity .RESULT_FIRST_USER 

Esso ci permette di non intralciare il normale funzionamento della piattaforma utilizzando valori in 
qualche modo già riservati. 

Fino a qui sembrerebbe essere tutto chiaro se non fosse per un problema: la riga evidenziata nel 
codice precedente non compila in quanto non esiste alcun overload del metodo putExtra ( ) che abbia 
come secondo parametro un oggetto di tipo UserModel. Una soluzione potrebbe essere quella di 
scomporre lo stato dell'oggetto e quindi trasmettere ogni sua parte attraverso un extra diverso. 
Potremmo quindi utilizzare un extra per lo username, uno per l'e-mail, la location e così via. Sebbene 
questo sia possibile non sarebbe sicuramente di semplice gestione; sarebbe facilissimo perdersi 
qualche valore oltre che avere una proliferazione di costanti per le varie chiavi 

Fortunatamente esiste una soluzione migliore, ossia rendere l'oggetto UserModel serializzabile o 
meglio "parcellizzabile". Ma perché? Come abbiamo detto più volte gli intent sono un meccanismo 
che permette ai diversi componenti di collaborare tra loro durante l'esecuzione di un'applicazione. 
L'aspetto importante è che si tratta comunque di componenti di applicazioni differenti che quindi sono 
in esecuzione in processi differenti. Per comunicare tra loro hanno bisogno di tecniche che si 
chiamano di IPC (Inter Process Communication). Non è possibile passare come parametro un 
oggetto direttamente da un processo a un altro semplicemente scambiandone il riferimento; si deve in 
qualche modo trasformare l'oggetto in array di byte e inviarlo al processo destinazione che quindi lo 
ricostruisce. Si parla quindi di serializzazione che, per motivi di performance, è stata reimplementata 
in quella che si chiama parcellizzazione e che ha la pretesa di essere specifica e quindi ottimizzata per 
la piattaforma Andro id. Nel prossimo paragrafo concluderemo la funzione di login creando due 
versioni di UserModel, una serializzabile e l'altra parcellizzabile. 

Passaggio di parametri di tipo Serializable 

Nei paragrafi precedenti abbiamo visto come un' activity invocata attraverso il metodo 
startActivityForResuit ( ) possa ritornare il proprio risultato incapsulato all'interno di un intent 
impostandolo come extra. Per fare questo abbiamo però la necessità di rendere la classe UserModel 
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di un tipo compatibile con quelli che sono i tipi di dato che possono essere inseriti come extra di un 
intent. A parte i tipi primitivi o gli array degli stessi, le due alternative sono quelle di oggetti serializzabili 
oppure parcellizzabili. In questo paragrafo ci occupiamo della prima opzione, creando una versione 
della classe userModei in un package diverso, e precisamente model . ser relativo al package 
dell'applicazione. 
NOTA 

Si tratta di uno stratagemma per non dover cambiare il nome della classe nei due casi ma solo il 
nome del package in fase di import. Purtroppo, per le prove, dovremo poi modificare tale package 
anche nella classe Loginservice. 

Rendere la nostra classe serializzabile è cosa molto semplice: consiste semplicemente 
nelT implementare l'interfaccia java.io.seriaiizabie, detta tagging interface inquanto non 
prevede la definizione di alcuna operazione. Serve solamente per marcare ima classe come tale. Fare 
in modo che una classe implementi tale interfaccia è una condizione necessaria ma non sufficiente, 
poiché si richiede che anche tutti i membri siano di tipo serializzabile. Nel nostro caso siamo fortunati, 
e la nostra classe diventa semplicemente la seguente: 

package uk . co . massimocarli . android. ugho .model .ser; 
public class UserModei implements Serializable { 

// Stesso body di UserModei in uk . co . massimocarli . android . ugho .model 

} 

Prima divedere se questa implementazione risolve il problema di compilazione, facciamo qualche 
osservazione relativamente a cosa significhi essere serializzabile e a quale possa essere il motivo per 
cui Google ha creato un nuovo meccanismo per raggiungere lo stesso risultato. 

Come accennato essere serializable significa poter essere trasformati in un array di byte per poi 
essere ricostruiti in un processo diverso. La serializzazione per come è intesa nel mondo Java prevede 
la sola trasformazione dello stato dell'oggetto e non della sua struttura ovvero della relativa classe. 
Per questo motivo il bytecode relativo alla classe dovrà essere disponibile in entrambi i processi che si 
scambiano questo tipo di oggetti Ma cosa succede nel caso in cui la versione della classe in possesso 
del primo processo fosse diversa da quella in possesso del secondo? Se non prendessimo alcun 
accorgimento si avrebbe un'eccezione, a cui possiamo ovviare attraverso l'utilizzo della costante che 
evidenziamo nel seguente codice: 

package uk . co . massimocarli . android. ugho .model .ser; 
public class UserModei implements Serializable { 

private static final long serialVersionUID = 7526471155622776147L; 

// Stesso body di UserModei in uk . co . massimocarli . android. ugho .model 

} 

che notiamo essere privata. Quando un oggetto deve essere ricostruito, l'ambiente Java calcola un 
valore di versione a meno che questo non sia già stato definito come nel codice precedente. Esso 
confronta quindi il valore della versione da ricostruire con quello a disposizione nel proprio bytecode. 
Se i due valori sono uguali, le versioni vengono considerate la stessa e quindi non si incorre in alcun 
problema a differenza del caso in cui tali valori fossero diversi. Quello descritto è quindi un aspetto a 
cui fare attenzione per non incorrere in errori di difficile individuazione. 

Il secondo aspetto riguarda una considerazione relativa al perché si è reso necessario un nuovo 
meccanismo di serializzazione. La risposta risiede probabilmente nella facilità con cui abbiamo reso la 
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nostra classe seriaiizabie, ovvero senza nessuna implementazione particolare o scrittura di codice. 
Questo significa che avviene un qualcosa in automatico che esamina la struttura dell'oggetto da 
serializzare, ne estrapola i valori e quindi li formatta in modo da poter ricostruire successivamente lo 
stesso oggetto in un altro processo. Come vedremo successivamente, questo nella parcellizzazione 
non avviene nel senso che è responsabilità dello sviluppatore decidere quale sarà il protocollo di 
lettura e di scrittura dello stato dell'oggetto. 

Fatte le modifiche di cui sopra notiamo come ora l'errore di compilazione sia sparito. Prima di 
proseguire con l'elaborazione del risultato nell'attività di partenza, vediamo il caso in cui la classe 
userModei è parcellizzabile. A tale proposito modificheremo la prima classe ovvero quella nel 
package relativo al modello dell'applicazione. 

Passaggio di parametri di tipo Parcelizable 

Al fine di ottimizzare la serializzazione di oggetto come quello da noi realizzato, i progettisti di 
Google hanno ideato un nuovo meccanismo che si chiama di parcellizzazione. È un meccanismo 
leggermente più complesso dal punto di vista dello sviluppo come possiamo vedere nella nuova 
versione della classe userModei, che notiamo da subito essere più impegnativa: 

public class UserModei implements Parcelable { 
private static final byte PRESENT = 1; 
private static final byte NOT_PRESENT = 0; 

public static final Parcelable . Creator<UserModel> CREATOR = 
new Parcelable . Creator<UserModel> ( ) { 

public UserModei createFromParcel (Parcel in) { 
return new UserModei (in) ; 

} 

public UserModei [] newArray(int size) { 
return new UserModei [size] ; 

} 

}; 

public UserModei (Parcel in) { 

this . mBirthDate = in . readLong ( ) ; 
if (in.readByte() == PRESENT) { 

this .mUsername = in . readString ( ) ; 

} 

if (in.readByte() == PRESENT) { 

this.mEmail = in . readString () ; 

} 

if (in.readByte() == PRESENT) { 
this .mLocation = (Location) 
in . readParcelable (getClass () . getClassLoader () ) ; 

} 

} 

gOverride 

public int describeContents () { 
return 0; 

} 

gOverride 

public void writeToParcel (Parcel dest, int flags) { 
dest .writeLong (mBirthDate) ; 
if ( ! TextUtils . isEmpty (mUsername) ) { 

dest . writeByte (PRESENT) ; 

dest . writeString (mUsername) ; 
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} else { 

dest . writeByte (NOT_PRESENT) ; 

} 

if ( !TextUtils. isEmpty (mEmail) ) { 

dest . writeByte (PRESENT) ; 

dest .writeString(mEmail) ; 
} else { 

dest . writeByte (NOT_PRESENT) ; 

} 

if ( !TextUtils . isEmpty (mLocation) ) { 

dest . writeByte (PRESENT) ; 

dest. writeString (mLocation) ; 
} else { 

dest . writeByte (NOT_PRESENT) ; 

} 

} 

// Stessa implementazione per gli altri metodi 

} 

Innanzitutto notiamo come l'interfaccia da implementare sia questa volta Parceiabie del package 
android. os che prevede, a differenza di quanto visto in precedenza, la definizione delle due 
operazioni: 

public void writeToParcel (Parcel dest, int flags) 
public int describeContents ( ) 

La prima dovrà contenere la logica di memorizzazione dello stato dell'oggetto all'interno di un 
Parcel che, senza entrare in dettagli, è il contenitore di tutti gli oggetti che verranno passati da un 
processo a un altro. Il secondo metodo permette invece di indicare se l'oggetto che stiamo gestendo 
è, come nella maggior parte dei casi, un oggetto che incapsula dei dati (come il nostro) oppure se è un 
riferimento a unFiieDescriptor, nel qual caso si utilizza come valore di ritorno quello dato dalla 

COStante Parcel .CONTENTS_FILE_DESCRIPTOR. 

Notiamo come il Parcel disponga di metodi del tipo writexxx ( ) per inserire in esso i valori dello 
stato del nostro oggetto. A differenza del caso precedente notiamo come il metodo di serializzazione 
debba essere implementato da noi e di come necessiti di alcuni trucchi per la gestione dei valori 
opzionali II primo valore inserito è infatti quello relativo alla data di nascita, che è sempre presente. Il 
secondo è invece relativo allo username, che invece è opzionale e per il quale abbiamo dovuto 
utilizzare il seguente codice: 

if ( ! TextUtils . isEmpty (mUsername) ) { 

dest . writeByte (PRESENT) ; 

dest .writeString (mUsername) ; 
} else { 

dest . writeByte (NOT_PRESENT) ; 

} 

Abbiamo infatti utilizzato un'informazione di un byte per indicare se il valore è presente oppure no. 
Lo stesso è stato poi fatto per l'informazione relativa all'e-mail e per quella relativa alla location. Per 
quest'ultima il metodo di salvataggio utilizzato è quello relativo alle proprietà a loro volta 
parcellizzabili. 

In fase di ricostruzione dell'oggetto dovremo quindi leggere le informazioni dal Parcel nello stesso 
ordine nel quale sono state scritte facendo ancora attenzione alla presenza o meno del byte che ne 
indica l'esistenza: 

public UserModel (Parcel in) { 

this .mBirthDate = in . readLong ( ) ; 
if (in.readByte() == PRESENT) { 
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this .mUsername = in . readString () ; 

} 

if (in.readByte() == PRESENT) { 

this . mEmail = in . readString () ; 

} 

if (in.readByteO == PRESENT) { 

this .mLocation = in . readString () ; 

} 

} 

Il lettore si potrebbe chiedere se questo byte sia necessario. In realtà non abbiamo scelta in quanto 
non potremmo avere diverse combinazioni di valori presenti oppure no e spesso di tipo diverso. 

Ma chi è il responsabile della "serializzazione" e "deserializzazione" secondo Android del nostro 
oggetto? L'oggetto misterioso è rappresentato dalla costante di nome creator, che ogni oggetto di 
tipo Parceiabie deve avere e che nel nostro caso è la seguente: 

public static final Parcelable . Creator<UserModel> CREATOR = 
new Parcelable . Creator<UserModel> ( ) { 
public UserModel createFromParcel (Parcel in) { 
return new UserModel (in) ; 

} 

public UserModel [] newArray(int size) { 
return new UserModel [size] ; 

} 

}; 

Si tratta di un'implementazione dell'interfaccia Parcelable .creator che il sistema utilizza per 
creare l'istanza dell'oggetto in fase di deparcellizzazione. 

Il lettore potrà verificare come l'utilizzo di questa classe non sia molto diverso da quella realizzata 
in precedenza se non da un punto di vista, comunque fondamentale, di prestazioni e integrazione con 
la piattaforma. 

Tornando alla nostra applicazione e sostituendo nuovamente il package corretto nel nostro 
LoginService e nella LoginActivity, noteremo come anche in questo caso non si abbia più un errore 
di compilazione. Uoverload del metodo putExtra o utilizzato sarà quello che prevede come secondo 
parametro un oggetto di tipo Parcelable. Sarà importante ricordarselo in fase di ricostruzione, come 
vedremo nel paragrafo successivo. 

Elaborazione del risultato 

Prima di proseguire facciamo un breve riassunto. Dopo aver creato la parte iniziale di navigazione 
della nostra applicazione, abbiamo iniziato l'implementazione della funzione di logjn che prevede 
l'utilizzo di una feature molto importante della piattaforma Android in termini di collaborazione tra i 
diversi componenti. Dall'attività descritta dalla classe FirstAccessActivity abbiamo delegato la 
funzione di logjn all'attività LoginActivity invocando la stessa attraverso il metodo 
startActivityForResuit o . Questo presuppone che l'attività di login raccolga le informazioni 
necessarie, invochi il servizio di autenticazione e quindi ritorni un'indicazione del risultato. I risultati 
possibili a questo punto sono due: il login avvenuto con successo oppure la cancellazione da parte 
dell'utente attraverso la pressione del pulsante Back. Gli eventuali errori di logjn sono infatti gestiti a 
livello di LoginActivity attraverso un opportuno messaggio di errore. L'invocazione del metodo 
finish o dopo quella del metodo setResuit o provoca nell'attività chiamante l'invocazione di un 
metodo che ha la seguente firma: 

protected void onActivityResult (int requestCode, int resultCode, Intent data) 
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i cui parametri hanno un significato molto importante. Il primo, di nome requestcode, è lo stesso 
valore che abbiamo utilizzato intàse di richiesta. Come accennato in precedenza ci permette di 
associare una risposta alla corrispondente richiesta. Questo anche perché mentre i punti di richiesta e 
quindi di invocazione del metodo startActivityForResuit o possono essere più di uno, quello di 
notifica del risultato è unico e necessita di un modo per distinguere i vari casi II secondo parametro è 
invece quello che indica l'esito dell'operazione e che abbiamo impostato attraverso il metodo 
setResuit o . Esso ci permetterà di sapere se l'utente ha cancellato l'operazione o se la stessa è 
avvenuta con successo. Il terzo parametro è quindi il più importante in quanto rappresenta il vero e 
proprio intent con i risultati, lo stesso che abbiamo quindi impostato attraverso il metodo 
setResuit ( ) . L'implementazione di questo metodo di callback è quindi la seguente: 

protected void onActivityResult (int requestCode, int resultCode, Intent data) { 
if (requestCode == LOGIN_REQUEST_ID) { 
switch (resultCode) { 
case RESULT_OK: 

final UserModel userModel = (UserModel) 

data . getParcelableExtra (LoginActivity . USER_DATA_EXTRA) ; 
final Intent mainlntent = new Intent (this, MenuActivity . class ) ; 
mainlntent .putExtra (MenuActivity .USER_EXTRA, userModel) ; 
startActivity (mainlntent) ; 
finish ( ) ; 
break; 
case RESULT_CANCELED : 
break; 

} 

} 

} 

Il primo controllo da lare è quello relativo all'azione richiesta, che qui è quella dilogia Per fare 
questo utilizziamo la costante login_request_id usata in fase di richiesta e il valore del parametro 
requestCode, e poi il valore del parametro resultCode per verificare qualè l'esito della richiesta. Nel 
caso di valore result_canceled significa che l'utente ha semplicemente premuto il pulsante Back per 
cui non dobbiamo fare nulla. Nel caso in cui invece il valore ottenuto sia result_ok significa che il 
login è avvenuto con successo per cui non dovremo fare altro che estrarre dall' intent ricevuto 
l'oggetto userModel che poi passiamo nuovamente alla MainAcitivìty. Il tutto si conclude con il 
finish ( ) di questa attività di passaggio. 

NOTA 

Il lettore avrà sicuramente la sensazione di come questo passaggio del modello descritto dalla 
classe userModel stoni un po' con quella che è la filosofia di Android di ottimizzare al massimo le 
prestazioni e l'interattività delle applicazioni. Vedremo in effetti nel capitolo dedicato alla persistenza 
come esistano dei modi migliori per la condivisione delle informazioni tra componenti diversi. 

Prima di proseguire notiamo come l'introduzione del modello ci induca a modificare il metodo di 
accesso anonimo nel seguente modo (per il momento per la selezione della data utilizziamo il 
componente DatePicker ma vedremo, nel Capitolo 5, come approfittare della cosa per crearne uno 
personalizzato): 

private void enterAsAnonymous ( ) { 

Log . d (TAG_LOG, "Anonymous access"); 

final Intent anonymous Intent = new Intent (this, MenuActivity . class) ; 
final UserModel userModel = UserModel . create (System . currentTimeMillis ()) ; 
anonymouslntent .putExtra (MenuActivity .USER_EXTRA, userModel) ; 
startActivity (anonymouslntent) ; 

} 

Nel CaSO di login riuscito, la LoginActivity ritornerà quindi alla FirstAccessActivity le 

informazioni relative all'utente incapsulate all'interno di un oggetto di tipo userModel che passeremo, 
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sempre attraverso un extra, all' activity del menu principale ovvero la MenuActivity. 



Implementiamo la registrazione 

In questo paragrafo vediamo velocemente come abbiamo implementato la funzionalità di 
registrazione ripetendo di fatto quanto scritto per il login. Innanzitutto abbiamo creato il documento di 
layout descritto dal file activity_registration . xml, di cui vediamo la preview nella Figura 3.30. 
Come possiamo osservare non abbiamo praticamente nulla di nuovo se non la presenza di un 
componente di nome DatePicker per la selezione della data di nascita (Birth date). 




Username: 



Password: 



Email: 

Birth date: 





+ 
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2013 










Location: 



Reg-ster 



Figura 3.30 Layout per la registrazione di un utente. 

Associato al layout abbiamo quindi creato l'attività descritta dalla classe RegìsterActivity, 

mentre il servizio utilizzato ora si chiama RegistrationService e ha una struttura analoga a quella di 

login. Anche in questo caso abbiamo definito un' action corrispondente all'azione di registrazione, che 

abbiamo definito nel file AndroidManif est . xml nel seguente modo: 

Octivity 

androidi: name=" . RegisterActivity" 

android: label="@string/ register_activity_label"> 
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<intent-f ilter> 
<action 

android : name="uk . co . massimocarli . android . ugho . action . REGISTRATION_ACTION" /> 

<category android : name=" android. intent . category . DEFAULT" /> 
</ intent-f ilter> 
</activity> 

e che abbiamo invocato nel seguente metodo eseguito a dopo la selezione del corrispondente 
pulsante: 

private void doRegistration ( ) { 

final Intent registrationlntent = new Intent (RegisterActivity .REGISTRATION_ACTION) ; 
startActivityForResult (registrationlntent, REGISTRATION_REQUEST_ID) ; 

} 

Notiamo come la costante utilizzata come secondo parametro del metodo 
startActivityForResult o sia ora diversa e associata appunto all'operazione di registrazione. 

Il meccanismo di comunicazione delle informazioni è lo stesso del logjn, per cui la parte più 
interessante riguarda il come il risultato venga gestito dalla classe Fir stAccessActivity. 

Abbiamo implementato il metodo digestione del risultato nel seguente modo: 

protected void onAotivityResult (int requestCode, int resultCode, Intent data) { 
if (requestCode == LOGIN_REQUEST_ID) { 

switch (resultCode) { 
case RESULT_OK: 

final UserModel userModel = (UserModel) data . getParcelableExtra 

(LoginActivity . USER_DATA_EXTRA) ; 
final Intent mainlntent = new Intent (this, MenuActìvity . class ) ; 
mainlntent .putExtra (MenuActivity .USER_EXTRA, userModel) ; 
startActivity (mainlntent) ; 
finish ( ) ; 
break; 
case RESULT_CANCELED: 
break; 

} 

} else if (requestCode == REGISTRATION_REQUEST_ID) { 

switch (resultCode) { 
case RESULT_OK: 

final UserModel userModel = (UserModel) data . getParcelableExtra 

(RegisterActivity . USER_DATA_EXTRA) ; 
final Intent detaillntent = new 
Intent (ShowUserDataActivity . SHOW_USER_ACTION) ; 

detaillntent .putExtra ( ShowUserDataActivity . USER_EXTRA, userModel) ; 
startActivity (detaillntent) ; 
break; 
case RESULT_CANCELED : 
break; 

} 

} 

} 

Vediamo come sia stato utilizzato il parametro requestCode per capire quale fosse il tipo di risposta 
per poi agire di conseguenza. Nel caso della registrazione non andiamo direttamente all'attività 
principale ma passiamo per un'attività riassuntiva dei dati inseriti Per questa abbiamo definito 
un'azione che abbiamo utilizzato per la definizione dell'attività nel file di configurazione 

AndroidManif est . xml: 
<activity 

android :name=" . ShowUserDataActivity" 

android: label="@string/ register_activity_label"> 

<intent-f ilter> 

<action android: name="uk . co .massimocarli . android. ugho . action . SHOW_USER_ACTION"/> 

< category android : name=" android. intent . category . DEFAULT" /> 
</ intent-f ilter> 
</activity> 

Per quello che riguarda il codice dell'attività ShowUserDataActivity, il lettore potrà notare come la 
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logica sia quella di semplice accesso al modello e quindi visualizzazione delle sue proprietà all'interno 
delle Textview di cui abbiamo ottenuto un riferimento. Degno di nota è il motivo per cui la 
valorizzazione dei campi è stata implementata nel metodo onResume ( ) e non nel metodo oncreate ( ) . 
Ricordiamo che il primo viene invocato per notificare che la nostra activity è attiva e può interagire 
con l'utente, mentre il secondo viene invocato solamente nel caso di creazione. Mettere tale logica nel 
metodo InResume ( ) ci consente di aggiornare i valori nel caso in cui si arrivasse all'attività attraverso 
la pressione di Back o comunque da un altro componente: 

protected void onResume () { 
super . onResume ( ) ; 

final String userName = mUserModel . getUsername () ; 

mUsername . setText (userName) ; 

final String email = mUserModel . getEmail () ; 

if (! TextUtils . isEmpty (email) ) { 

mEmail . setText (email ) ; 
} else { 

mEmail . setText ("-") ; 

} 

final DateFormat format = DateFormat . getDatelnstance (DateFormat .MEDIUM) ; 

Calendar calendar = Calendar . getlnstance ( ) ; 

calendar . setTimelnMillis (mUserModel . getBirthDate ( ) ) ; 

final String bìrthDate = format . format (calendar . getTime ()) ; 

mBirthDate . setText (birthDate ) ; 

final String location = mUserModel . getLocation () ; 
ìf (! TextUtils . isEmpty (location) ) { 

mLocation . setText (location) ; 
} else { 

mLocation . setText ( "-" ) ; 

} 

} 

La pressione del pulsante di conferma ci porta quindi all'attività di menu come nel caso del logjn 
visto in precedenza. 



Conclusioni 

Siamo così giunti al termine di questo lungo e impegnativo capitolo, che ci ha permesso di vedere 
moltissimi aspetti relativi alla creazione di un'applicazione nel mondo Android. Come accennato fin da 
subito abbiamo scelto questo approccio molto pratico per arrivare il prima possibile alla realizzazione 
di un'applicazione passando comunque per affinamenti e l'introduzione di feature in modo 
incrementale. Molti dei concetti visti verranno ulteriormente approfonditi Lasciamo al lettore la 
visione del codice relativo alla navigazione verso le altre activity al momento prive degli elementi che li 
caratterizzano e quindi con layout praticamente vuoti Nel prossimo capitolo vedremo come 
preparare la nostra applicazione all'esecuzione su tablet attraverso l'utilizzo di quelli che si chiamano 
fragment. 
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Capitolo 4 



Gestire display di dimensioni diverse: i 

fragment 



Nel capitolo precedente abbiamo visto molti concetti fondamentali della programmazione Android 
attraverso la creazione di un progetto e l' implementazione del flusso di navigazione. Gran parte della 
discussione è stata concentrata sul concetto di activity, che abbiamo più volte detto essere associato 
a quello di schermata. L'aspetto che abbiamo invece completamente trascurato riguarda il tipo di 
dispositivo che andrà a eseguire l'applicazione e più in particolare quale sarà la dimensione del 
corrispondente display. Una delle principali caratteristiche della piattaforma Android è infatti la grande 
predisposizione alle personalizzazioni, che però ha portato alla messa sul mercato di dispositivi anche 
molto diversi tra loro. Il nostro obiettivo è l'installazione dell'applicazione sul numero maggiore dei 
dispositivi, per cui dovremo adottare tutti gli accorgimenti possibili per fare in modo che questo 
avvenga. Google conosce benissimo il problema e non esce una nuova versione di Android che non 
faccia un qualche passo in avanti in tal senso. 

Uno di questi aspetti è quello relativo alla dimensione della UI e quindi alla possibilità di posizionare 
in modo diversi i vari componenti. Per risolvere il problema è stato introdotto il concetto difragment, 
al quale dedicheremo la prima parte del capitolo. Un altro accorgimento ha riguardato invece quello 
che abbiamo già visto essere TAPI Level, un indicatore della particolare versione dell'ambiente nel 
dispositivo. Per esempio, i fragment sono stati introdotti con la 3.0 (ApiLevel 11) e quindi l'utilizzo di 
questo strumento precluderebbe la nostra applicazione dei dispositivi con versioni inferiori. Per 
ovviare a questo inconveniente, è stata resa disponibile quella che si chiama Compatibility Library, 
la quale cerca di uniformare le varie piattaforme dalla 1.6 in poi. 

In questo capitolo vedremo nel dettaglio i vari tipi di fragment per poi sfruttare i concetti studiati 
nella nostra applicazione in modo che la stessa assuma una UI dipendente dalla dimensione del 
display. Faremo in modo che su un tablet la disposizione dei vari componenti grafici sia diversa 
rispetto a quella in esecuzione su uno smartphone. Anche l'utilizzo dei qualificatori giocherà la sua 
parte. 

I fragment 

Abbiamo più volte detto che le activity rappresentano probabilmente il tipo di componente più 
importante nell'architettura Android in quanto le possiamo associare alla schermata che contiene gli 
strumenti di interazione con l'utente. Nel capitolo precedente ne abbiamo studiato a fondo il ciclo di 
vita. Come sappiamo a ogni attività corrisponde un layout che nella stragrande maggioranza dei casi 
descriviamo in modo dichiarativo attraverso un documento XML di layout. Non tutti i dispositivi però 
sono uguali Alcuni sono piccoli come nello smartphone e altri sono molto grandi (più di 10 pollici) 
come nei tablet e potenzialmente grandissimi come nella Google TV, e quindi necessitano di una 
disposizione di componenti che ne sfrutti al massimo lo spazio. Per comprendere meglio il problema 
facciamo un esempio concreto, riferendosi a un'applicazione composta da due attività principali. La 
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prima, ActivityList, permette la visualizzazione di un elenco di elementi selezionando i quali è 
possibile visualizzare un dettaglio attraverso una seconda attività ActivityDetaii. Se supponiamo di 
eseguire l'applicazione in imo smartphone otterremo imo scenario come quello nella Figura 4.1. La 
prima attività visualizza una lista di elementi (per esempio notizie) che, se selezionati, forniscono la 
visualizzazione del corrispondente dettaglio attraverso una seconda attività. L'utente può premere il 
pulsante Back e selezionare una seconda notizia di cui visualizzare il dettaglio utilizzando sempre la 
stessa attività ActivityDetaii. Il tutto viene eseguito senza problemi a meno che non si voglia 
utilizzare un dispositivo con display classificato come x-large ovvero un tablet. A differenza degli 
smartphone, i tablet vengono utilizzati principalmente in modalità landscape. 

A questo punto è abbastanza semplice comprendere come le due attività precedenti non 
permettano uno sfruttamento ideale dello spazio a disposizione. Avremmo infatti una lista prima, e poi 
un dettaglio di larghezza esagerata rispetto a quello che effettivamente servirebbe. In questo secondo 
caso, sarebbe molto più efficiente gestire il tutto con il meccanismo descritto nella Figura 4.2, dove si 
posiziona la lista nella parte sinistra e il dettaglio corrispondente all'elemento selezionato nella parte a 
destra. 

A ogni selezione dell'elemento nella lista corrisponde la visualizzazione del relativo dettaglio nella 
parte destra. Qui si potrebbe osservare un diverso comportamento del pulsante Back. Nel primo 
scenario si ha il normale comportamento che torna da un'attività alla precedente all'interno dello 
stesso task. Nel secondo caso serve qualcosa di diverso in quanto è possibile rendere attiva una sola 
activity alla volta. La pressione del pulsante Back dovrebbe avere come effetto la visualizzazione 
dell'eventuale dettaglio precedente o l'uscita dall'applicazione nel caso in cui tale dettaglio non 
esistesse perché all'inizio della navigazione. 
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Figura 4.1 Visualizzazione di lista e dettaglio in uno smartphone. 



FragmentList 



FragmentDetail 



Detail 1 



Figura 4.2 Utilizzo dei fragment per una modularizzazione della Ul. 



Da quanto detto capiamo comunque che le sole activity non bastano e si ha la necessità di 
qualcosa di diverso che prende appunto il nome difragment, e che è descritto da particolari 
specializzazioni dell'omonima classe del package android. app. È un componente diverso dall' activity, 
che consente di gestire delle sotto- attività non solo per quello che riguarda la loro UI ma anche la loro 
history, quel meccanismo che permette di mantenere lo stato di navigazione per la gestione del 
pulsante Back. 



Il classico Master Detail 

Prima di rendere la nostra applicazione UGHO compatibile con la gestione dei fragment, 
realizziamo insieme un progetto di esempio di nome FragmentTest. Per fare questo seguiamo la stessa 
procedura utilizzata nel capitolo precedente fino ad arrivare alla schermata nella Figura 4.3, relativa al 
tipo di activity iniziale da creare. Come indicato nella figura, scegliamo di utilizzare l'opzione 
identificata da Master/Detail Flow. 
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New Project 
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NEW 

PROJECT 



(?) [_Cancel 



Blank ActMty 
Fullscreen ActMty 
Login ActMty 



Master/Detail Flow 



Settings Activrty 




Description 

Creates a new master/detail flow, allowing users to view a collection of objects as well as 
details for each object. This flow is presented using two columns on tablet-size screens and 
one column on handsets and smaller screens. This template creates two activìties, a master 
fragment, and a detail fragment. 



Previous 



Figura 4.3 Selezione dell'opzione Master/Detail Flow. 

Selezionando il pulsante Next ci viene proposto un nuovo forni dove inserire le inforrnazioni 
relative al nome dell'entità che intendiamo rappresentare sia nella forma singolare sia plurale. 
ATTENZIONE 

Questa opzione dell'ADP è disponibile solamente per versioni della piattaforma successive alla 3.0 
ovvero all'API Level 11. In realtà i fragment possono essere utilizzati anche in versioni precedenti 
attraverso la Compatibility Library ma il plug-in, al momento, non ne tiene conto. 

Nel nostro caso utilizziamo i valori Notizia e Notizie come nella Figura 4.4. 
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New Project 



Object Kind 
Object Kind Plural 



Notizia 



Notizie 



Description 

Other examples are 'People', 'Books', etc. 



Previous 



Figura 4.4 Inserimento del nome degli oggetti rappresentati. 

A questo punto viene creato automaticamente un progetto che consente la navigazione descritta in 
precedenza e che andiamo a vedere nel dettaglio approfittando anche dell'occasione per considerare 
alcune proprietà del linguaggio Java che stiamo utilizzando. In questa fase Andro id Studio scaricherà 
le librerie necessarie alla compilazione ed esecuzione dell'applicazione utilizzando il sistema dibuild di 
nome Gradle che abbiamo visto nelle parti principali nel capitolo precedente. Il lettore potrà poi 
notare come, avendo scelto l'opzione New > Project e non quella di creazione di un nuovo Module, 
il tool visualizzerà, all'interno di una nuova finestra, ima struttura analoga a quella vista per UGHO, 
che abbiamo riportato nella Figura 4.5. 

Come prima cosa rileviamo la presenza di un package dummy (relativo al package 
dell'applicazione) che contiene la classe Dummy Content che rappresenta il nostro modello e i dati che 
andremo a visualizzare nella UI. È una classe con dei valori cablati che potremo comunque sostituire 
con altrettanti presi dalla rete o da un database locale: 

public class DummyContent { 

public static List<DummyItem> ITEMS = new ArrayList<DummyItem> ( ) ; 

public static Map<String, Dummyltem> ITEM_MAP = new HashMap<String, Dummyltem> ( ) ; 



static { 

addltem(new Dummy Item (" 1 " , "Item 1")); 
addltem(new Dummyltem ( "2 " , "Item 2")); 
addltem(new Dummyltem (" 3 " , "Item 3")); 

} 
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private static void addltem (Dummyltem itera) { 
ITEMS . add (itera) ; 
ITEM_MAP .put (item. id, itera); 

} 

public static class Dumrayltem { 
public String id; 
public String content; 

public Dumrayltem (String id, String content) { 
this.ìd = id; 
this. content = content; 

} 

SOverride 

public String toStringO { 
return content; 

} 
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Figura 4.5 Struttura delle directory per il nuovo progetto di test. 
NOTA 

In sintesi il tool ci presenta un semilavorato di un'applicazione lasciando indefinite alcune parti, 
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come stiamo facendo con la nostra applicazione allo scopo di introdurre i vari strumenti di volta in 
volta. 

Osservando il codice riportato vediamo che c'è una classe interna statica di nome |)ummyltem. 
Ricordiamo che una classe interna statica è una classe che ha un legame solamente logico con quella 
che la contiene. Questo significa che le eventuali istanze non sono per nulla legate a una particolare 
istanza della classe padre. In pratica è semplicemente una classe di nome DummyContent .Dummyitem 
che ci permette di descrivere gli elementi da visualizzare. 

NOTA 

Per chi ha esperienza di sviluppo Java in ambiente enterprise, e come accennato nel Capitolo 1, 
notiamo come questa classe utilizzi variabili public invece che le corrispondenti private con i relativi 
metodo g et/ se t. Questa è una prassi utilizzata spesso in ambiente mobile, dove l'utilizzo dei metodi 
accessor e mutator viene considerato superfluo. 

In questo esempio essi sono caratterizzati da un id e da un content entrambi di tipo String. Tutti i 
dati di questo tipo vengono poi memorizzati all'interno di una lista così definita: 

public static List<DummyItem> ITEMS = new ArrayList<DummyItem> ( ) ; 

la quale viene inizializzata nel prossimo blocco che prende il nome di inizializzatore statico: 

static { 

// Aggiunta di tre elementi d'esempio. 
addltem(new Dummyltem ( " 1 " , "Item 1 " ) ) ; 
addltem(new Dummyltem ( "2 " , "Item 2")); 
addltem(new Dummyltem ( "3 " , "Item 3")); 

} 

Si tratta di un blocco che viene eseguito una sola volta al momento del caricamento della classe da 
parte del ciassLoader. Le inizializzazioni di membri statici, compresi i blocchi, sono caratterizzate dal 
latto di essere eseguite nello stesso ordine in cui sono scritte all'interno della classe. Si tratta di 
blocchi che, essendo statici, possono accedere solamente a membri statici della classe. 

NOTA 

Il ciassLoader è quel particolare oggetto che ha il compito di caricare il bytecode che verrà poi 
eseguito. È un componente che spesso ha anche responsabilità di sicurezza per impedire il 
caricamento di dati non sicuri da fonti di codice non certe. 

Il metodo additemo consente semplicemente di associare ogni Dummyltem al corrispondente id in 
una Map per poi ottenerne un riferimento più veloce in làse di selezione dalla lista: 

public static Map<String, Dummyltem> ITEM_MAP = new HashMap<String, Dummyltem> ( ) ; 

private static void addltem (Dummyltem item) { 
ITEMS . add (item) ; 
ITEM_MAP .put (item. id, item); 

} 

Nel package relativo all'applicazione vediamo due attività e due fragment, imo legato alla lista di 
elementi e un altro dedicato al dettaglio. Ci concentriamo inizialmente sul fragment descritto dalla 
classe NotiziaList Fragment. Come prima cosa notiamo che si tratta di ima classe che estende la 
classe ListFragment, ima particolare specializzazione di fragment a cui è già stato associato un layout 
contenente una lista e che racchiude già alcuni metodi di utilità per la visualizzazione degli elementi e la 
corrispondente selezione. 

NOTA 

La gestione delle liste all'interno dei componenti Ul Android è fondamentale, per cui le dedicheremo 
gran parte del Capitolo 5. 

Una prima fondamentale osservazione riguarda la presenza, analogamente a quanto avviene per le 
activity, di alcuni metodi di callback che verranno invocati in corrispondenza di particolari stati del 
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ciclo di vita del fragment (che descriveremo nel paragrafo successivo). Per il momento rileviamo la 
presenza di un costruttore di detàult 

public NotiziaListFragment ( ) { 
} 

che andremo a invocare, attraverso l'operatore new, dall'attività per la creazione dell'istanza da 
utilizzare. 
NOTA 

La presenza di un costruttore di default è una condizione necessaria specialmente se il fragment 
viene creato direttamente dal layout e non attraverso la scrittura di codice. Nelle ultime versioni del 
plug-in, la sua assenza provoca un errore in fase di validazione del codice, impedendone quindi la 
compilazione. 

Dopo la creazione dell'istanza del fragment, il metodo invocato dal sistema è onAttach ( ) , che ci 
offre ropportunità di ottenere un riferimento all'activity contenitore. Questo può avvenire secondo 
diversi livelli di astrazione. Se i fragment sono utilizzati sempre dalla stessa attività è possibile utilizzare 
un riferimento di tipo corrispondente all'activity stessa. Per essere più espliciti, è comune 
implementare il metodo onAttach o come segue: 

private NotiziaListActivity mActivity; 
public void onAttach (Activity activity) { 

super . onAttach (activity) ; 

this .mActivity = (NotiziaListActivity) activity; 

} 

In questo modo abbiamo un riferimento all'attività che ci permette di accedere a tutti i metodi (non 
privati) in essa definiti Come sappiamo questo può andare bene ma ha un livello di accoppiamento 
con rattività troppo forte che non ci consente di riutilizzare lo stesso fragment con altre activity. 
Questo è il motivo per cui, nel nostro esempio, è stata definita prima la seguente interfaccia interna: 

public interface Callbacks { 

public void onltemSelected (String id) ; 

} 

e quindi ne è stata fornita un'implementazione di defàult 

private static Callbacks sDummyCallbacks = new Callbacks () { 
SOverride 

public void onltemSelected (String id) { 
} 

}; 

Il metodo onAttach o è poi stato implementato così; 

private Callbacks mCallbacks = sDummyCallbacks; 
HOverrìde 

public void onAttach (Activity activity) { 
super . onAttach (activity ) ; 
if ( ! (activity instanceof Callbacks) ) { 

throw new IllegalStateExceptìon ( "Activity must implement fragment ' s 
callbacks . " ) ; 
} 

mCallbacks = (Callbacks) activity; 

} 

Questo ci permette di ottenere un riferimento all'activity in quanto oggetto che implementa 
un' interfaccia di callback e che dispone del metodo onltemSelected ( ) che utilizzeremo dal fragment 
per notificare la selezione di un elemento della lista. 

Una volta che il fragment è stato associato a un'attività, viene invocato il metodo Increate ( ) , che 
nel nostro caso 

public void onCreate (Bundle savedlnstanceState) { 
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super . onCreate (savedlnstanceState) ; 

setListAdapter (new ArrayAdapter<DummyContent . Dummyltem> ( 
getActivity ( ) , 

android . R . layout . simple_list_item_activated_l , 
android.R. id.textl, DummyContent . ITEMS) ) ; 

} 

La firma del metodo è esattamente la stessa che abbiamo per le activity, come lo stesso è il 
significato del parametro di tipo Bundie che andremo a utilizzare per la gestione dello stato associato 
al fragment e che intende risolvere lo stesso problema che avevamo per le activity. In questo metodo 
si eseguono tutte quelle operazioni di inizializzazione legate al componente che qui si traducono 
nell'assegnazione di un adapter. 

NOTA 

Nel Capitolo 6 vedremo nel dettaglio che cos' è un adapter. Per il momento consideriamolo come un 
componente in grado di accedere a delle informazioni memorizzate in una base dati e creare delle 
view per la loro visualizzazione. 

In sintesi, una lista non fera altro che richiedere a un adapter quale view utilizzare per la 
rappresentazione di un elemento in una particolare posizione. Esistono molte implementazioni di 
adapter ma nel nostro caso utilizziamo quella che prende le informazioni da un array (nel nostro caso 
items della classe DummyContent), e le rappresenta utilizzando il layout predefinito associato alla 
costante android.R. layout. simpie_iist_item_activated_i contenente una Textview identificata da 
android . R. id. text i. Il commento nel codice ci fa pensare che esisterà un metodo per personalizzare 
questo layout e per associare a ciascun attributo del modello (nel nostro caso 
DummyContent . Dummyitem) la corrispondente view nel layout che lo dovrà rappresentare. Qui il 
risultato sarà la semplice visualizzazione di un elenco óìString. 

A questo punto il fragment viene creato e gli viene associato un layout all'interno 
dell'implementazione del metodo onCreateView ( ) . In questo caso il nostro fragment estende la classe 
ListFragment, la quale fornisce già un'implementazione di defeult del metodo onCreateView ( ) , che 
crea appunto una lista che dovremo poi andare a valorizzare. 

NOTA 

La lista è associata alla costante android.R. id.ust. Di solito il layout contiene anche il riferimento a 
una Textview che viene visualizzata nel caso in cui l'adapter non fornisca informazioni da visualizzare 
e quindi la lista sia vuota. Esso è associato alla costante android . R . ìd . empty. 

Il metodo invocato, successivamente all'associazione della view, è onviewcreated o , che nel 
nostro caso è implementato così: 

private statìc final String STATE_ACTIVATED_POSITION = "actìvated_position" ; 
dOverride 

public void onViewCreated (View view, Bundle savedlnstanceState) { 

super . onViewCreated (view, savedlnstanceState) ; 

ìf (savedlnstanceState != nuli && 

savedlnstanceState . containsKey (STATE_ACTIVATED_POSITION) ) { 
setActivatedPosition (savedlnstanceState . getlnt (STATE_ACTIVATED_POSITION) ) ; 

} 

} 

private void setActivatedPosition ( int position) { 
if (position == ListView. INVALID_POSITION) { 

getListView ( ) . setltemChecked (mActivatedPosition, false); 
} else { 

getListView ( ) . setltemChecked (position, true) ; 

} 

mActivatedPosition = position; 

} 

144 



La prima osservazione riguarda la presenza del parametro di tipo Bundie che potrebbe contenere 
lo stato del nostro fragment e che potremmo voler ripristinare. Per questo motivo è stata definita la 
costante state_activated_position per leggere la posizione correntemente selezionata nel momento 
della rotazione del display. Se disponibile, viene invocato un metodo di utilità di nome 
setAotivatedPosition ( ) , che memorizza l'indice dell'elemento selezionato nella variabile d'istanza 
mActivatedPosition dopo aver selezionato tale indice nella lista. 

Avendo utilizzato come layout della lista quello identificato dalla costante 

android.R. layout. simple_list_item_activated_l, l'invocazione delmetodo setltemChecked ( ) ha 

come effetto la visualizzazione di un'icona che ne indica la selezione. Questa ha senso solamente nel 
caso del tablet in quanto, nel caso dello smartphone, l'attività della lista verrebbe sostituita con quella 
del dettaglio nel caso landscape. 

Una volta descritto il fragment relativo alla lista passiamo alla corrispondente attività descritta dalla 
classe NotiziaListActivity. L'utilizzo dei nuovi componenti ci consente di semplificare le attività 
dando loro solamente la responsabilità di controller, ovvero di coordinamento. Nel nostro esempio è 
una classe che implementa l'interfaccia Iloti zi aListFragment . Callback e che quindi dispone del 
metodo da eseguire nel caso di selezione di un elemento della lista. Rileviamo inoltre come si tratti di 
una classe che estende FragmentAotivity, che è una particolare specializzazione della classe 
Activity che ci permette di utilizzare i fragment anche in versioni precedenti la 3.0. 

NOTA 

Questa osservazione ci porta a pensare che la limitazione precedente sia effettivamente solo legata 
a un problema del plug-in. Il codice generato è infatti valido anche nelle versioni precedenti la 3.0 
proprio per l'utilizzo degli strumenti messi a disposizione dalla Compatibility Library. 

Questa classe ha inoltre la responsabilità di capire se viene eseguita all'interno di un dispositivo con 
schermo classificato come x-large oppure no. E una logica definita all'interno delmetodo oncreate o 
e che utilizza il meccanismo alla base della gestione delle risorse: 

private boolean mTwoPane; 
HOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_notizia_list) ; 
if (f indViewByld (R. id. notizia_detail_container) != nuli) { 

mTwoPane = true; 

( (NotiziaListFragment ) getSupportFragmentManager ( ) 
. f indFragmentByld (R. ìd . notizia_list ) ) 
. setActivateOnltemClick (true) ; 

} 

} 

Abbiamo visto più volte come il metodo onCreate ( ) abbia la responsabilità di impostare i layout 
dell'attività come avviene anche qui con il layout r. layout . activity_notizia_iist. Se andiamo a 
osservare le risorse notiamo però come non siano presenti dei qualificatori sulle risorse di tipo layout 
bensì viene utilizzata un'altra feature relativa alla gestione degli alias. In sostanza è possibile, per ogni 
tipo di risorsa, fornire dei valori alternativi che verranno utilizzati al posto della risorsa originale se 
selezionati in corrispondenza di determinati qualificatori. Il layout è caratterizzato da un elemento di 
tipo <fragment/> che definisce, attraverso l'attributo androìd:name, il nome completo della classe 
che lo descrive. 

NOTA 

La presenza di questa modalità di creazione di un fragment è la ragione per cui si richiede la 
presenza del costruttore di default. 
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<f ragment xmlns : android="http : //schemas . android . com/ apk/res/android" 
xmlns : tool s=" http : //schemas . android . com/tools" 
android : id=" @+id/ notizia_list " 

android: name="uk . co .massimocarli . android. fragmenttest . Noti ziaListFragment" 

android : layout_width="match_parent " 

android : layout_height="match__parent " 

android: layout_marginLef t=" 1 6dp" 

android : layout_marginRight=" 1 6dp" 

tools : context=" .NotiziaListActivity" 

tools : layout="@android: layout/list_content " /> 

Se andiamo poi a osservare le risorse notiamo la presenza delle seguenti cartelle: 

/values-large 
/values-sw600dp 

che contengono lo stesso file ref s .xml con questa definizione: 

<resources> 

<item name="activity_notizia_list" type="layout">@layout/activity_notizia_twopane< 

item> 

</ resources> 

che, attraverso l'elemento <item/>, definisce un alias per una risorsa di tipo layout (definita 

attraverso l'attributo type) che fa riferimento al layout rappresentato dalla costante 

R. layout . activity_notizia_twopane. In sostanza, per quei dispositivi le cui caratteristiche sono 

compatibili con i qualificatori utilizzati, un riferimento al layout activity_notizia_iìst è invece un 

riferimento al layout act i vit y_not i z i a_twopane, che è il seguente: 

<LinearLayout xmlns : android="http : / /schemas . android . com/ apk/res/ android" 
xmlns : tool s=" http : //schemas . android . com/tools" 
android: layout_width="match__parent " 
android: layout_height="match__parent " 
android : layout_marginLef t=" 1 6dp" 
android: layout_marginRight=" 1 6dp" 
android : baselineAligned= "false" 

android : divider=" ? android : attr/ divider Horizont al " 

android : orìentation=" horizont al" 

android: showDividers="middle " 

tools : context=" .NotiziaListActivity"> 

<f ragment 

android : id=" @+id/notizia_list " 

android: name="uk . co . massimocarli . android. fragmenttest . Noti ziaListFragment" 
android: layout_ 

android: layout_height="match_parent " 
android: layout_weight=" 1 " 

tools : layout="@android: layout/list_content" /> 

<FrameLayout 

android: id="@+id/notizia_detail_container" 
android: layout_ 

android : layout_height= "match__parent " 
android: layout_weight=" 3" /> 

</LinearLayout> 

Qui, oltre al fragment con l'elenco degli item, abbiamo anche un FrameLayout che verrà utilizzato 
come contenitore del fragment di dettaglio. Tornando ai qualificatori utilizzati, vediamo come essi 
facciano riferimento ai dispositivi con display classificato come large e a quelli con display la cui 
larghezza inferiore è comunque di almeno 600 dp. Abbiamo la necessità di inserire entrambi per 
comprendere i dispositivi con Android 3.2. 

Le definizioni precedenti ci permettono di assegnare un layout diverso a seconda delle 
caratteristiche del dispositivo attraverso l'utilizzo di alias. L'attività è comunque sempre la stessa e 
deve capire in quale situazione si trova al fine di eseguire la corretta operazione a seguito della 
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selezione di un elemento della lista. Nel caso dello smartphone, dovremo lanciare Fattività di dettaglio, 
mentre nel caso dei tablet dovremo visualizzare il fragment di dettaglio nella parte destra. Questa 
logica è codificata all'interno del metodo oncreate o descritto, sopra dove viene verificata la 
presenza della view associata alla costante r. id.notizia_detaii_container. Nel caso dello 
smartphone questo componente non è presente in quanto non viene selezionato il layout 
activity_notizia_twopane che lo definisce. Oltre a impostare il valore della variabile che ci ricorda 
in quale situazione di layout siamo, è importante osservare questo codice: 

( (NotiziaListFragment ) getSupportFragmentManager ( ) 
. f indFragmentByld (R. id. notizia_list ) ) 
. setActivateOnltemClick (true ) ; 

che ci consente di interagire con il fragment definito nel layout attraverso un oggetto di tipo 

FragmentManager Ottenuto COme valore di ritorno del metodo getSupportFragmentManager ( ) e che 

rappresenta l'oggetto fondamentale per la gestione dei fragment. Il metodo 
setActivateOnltemClick ( ) , definito in NotiziaListFragment, non farà altro che impostare la 
modalità di selezione nella lista per abilitare o meno l'effètto di selezionato. 

Di maggior interesse è l'implementazione del metodo che viene invocato, tramite ilcallback, in 
corrispondenza della selezione di un elemento della lista: 

public void onltemSelected (String id) { 
if (mTwoPane) { 

Bundle argument s = new Bundle ( ) ; 

arguments.putString(NotiziaDetailFragment.ARG_ITEM_ID, id) ; 
NotiziaDetailFragment fragment = new NotiziaDetailFragment () ; 
fragment . setArguments (arguments) ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 

. replace (R. id.notizia_detail_container, 

fragment) .commit () ; 

} else { 

Intent detaillntent = new Intent (this, NotiziaDetailActivity . class ) ; 
detaillntent .putExtra (NotiziaDetailFragment . ARG_ITEM_ID, id) ; 
startActivity (detaillntent) ; 

} 

} 

Come possiamo vedere, si utilizza la variabile mTwoPane, impostata precedentemente, per capire in 
quale situazione ci si trova. Nel caso in cui il valore sia false si utilizza la modalità già vista, cioè si 
crea un intent esplicito verso l'attività di dettaglio, si inserisce come extra l'identificatore della notizia 
selezionata e poi si esegue il metodo startActivity ( > . Nel caso della modalità tablet, vediamo come 
il parametro venga passato attraverso un oggetto Bundle assegnato al fragment attraverso il metodo 
setArguments ( ) . A questo punto si utilizza il FragmentManager per sostituire, attraverso il metodo 
replace ( ) , il fragment attuale con quello relativo al dettaglio appena selezionato. Notiamo una novità 
rispetto a quanto già visto, ovvero la presenza di una transazione che inizia con l'invocazione del 
metodo beginTransaction ( ) e termina con il commit ( ) . Il contenuto della transazione è l'operazione 
che permette la sostituzione del fragment con quello voluto. L'utilità di un meccanismo di questo tipo è 
che spesso un'operazione di selezione non ha come unica conseguenza la sostituzione di un fragment 
ma può essere caratterizzata da un numero maggiore di operazioni che è bene considerare come 
unico all'interno di una transazione. È un aspetto molto importante della gestione dei fragment che 
affronteremo in un paragrafo successivo. 

Tornando alla nostra applicazione di esempio non ci resta che esaminare la parte relativa al 
dettaglio, cioè l'attività NotiziaDetailActivity, e il fragment descritto dalla classe 
NotiziaDetailFragment. L'attività è ora molto semplice e contiene il codice che consente la 



147 



visualizzazione del fragment inizializzato con l'identificatore della notizia da visualizzare. 
NOTA 

In realtà questa attività contiene alcune istruzioni per la gestione dell'action bar, che approfondiremo 
nel Capitolo 7 insieme a una libreria molto utilizzata e che prende il nome di ActionBarSherlock. 

Anche la classe NotiziaDetaiiFragment è ora di semplice lettura. Da sottolineare solamente la 
modalità di accesso alle informazioni memorizzate come argomenti attraverso le seguenti istruzioni: 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
if (getArguments () . containsKey (ARG_ITEM_ID) ) { 

mltem = DummyContent . ITEM_MAP .get (getArguments () . getString (ARG_ITEM_ID) ) ; 

} 

} 

Diversamente dal caso precedente, qui abbiamo l' implementazione del metodo l nCreate View ( ) , 
la cui responsabilità è quella di assegnare il layout al fragment come avviene anche qui: 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, 
Bundle savedlnstanceState) { 

View rootview = inflater . inf late (R. layout . fragment_notizia_detail, container, 
false) ; 

if (mltem != nuli) { 

( (TextView) rootview . f indViewByld (R. id . notizia_detail ) ) . setText (mltem. content ) ; 

} 

return rootview; 

} 

Da notare come la creazione della view da utilizzare come layout avvenga attraverso un oggetto di 
tipo Layout inflater passato come parametro attraverso un'operazione di in/late. 

Ciclo di vita di un fragment 

Come visto con le activity e come già accennato, anche i fragment sono caratterizzati da un proprio 
ciclo di vita che è bene conoscere al fine di un uso ottimale delle risorse. Non si può utilizzare un 
fragment senza un'attività che lo contenga, per cui i due cicli di vita dovranno sicuramente essere 
legati tra loro, come mostrato nella Figura 4.6. Come visto nell'esercizio precedente, i fragment 
possono essere aggiunti o rimossi e sono quindi soggetti a un proprio ciclo di vita comunque legato a 
quello dell'attività che li contiene. 
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Figura 4.6 Ciclo di vita di un fragment. 

La prima operazione da eseguire Dell'utilizzo di un fragment è la creazione, che può avvenire 
sostanzialmente in due modi diversi che comunque dovranno garantire la presenza del costruttore di 
defàult per quando detto in precedenza. 

• Implementazione di un metodo statico di Factory. 

• Utilizzo nel layout del tag <f ragment/>. 

La prima modalità è semplicemente un modo per creare un'istanza del fragment passando tutto 
quello di cui lo stesso necessita e che verrà salvato all'interno di un Bundie che viene associato al 
concetto di parametri o argomenti Questa modalità non è legata strettamente alla piattaforma 
Andro id ma descrive semplicemente una buona regola di programmazione. Nel caso in cui un 
fragment (lo stesso vale per una qualunque classe) avesse bisogno, per esempio, di due valori per due 
sue proprietà ritenute essenziali una prima soluzione potrebbe essere la seguente 

MyFragment frag = new MyFragment () ; 
f rag . setArgl (argl ) ; 
frag . setArg2 (arg2 ) ; 

Si tratta di tre istruzioni durante l'esecuzione delle quali l'istanza frag non ha uno stato consistente 
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in quanto abbiamo detto che i suoi argomenti sono essenziali. Una soluzione consiste 
nell'implementazione di quello che si chiama static factory method: 

public static MyFragment getMyFragment (String argl, int args2 ){ 
MyFragment myFrag = new MyFragment () ; 

Bundle args = new BundleO; 
args . putString (KEY1 , argl); 
args .put Int (KEY2 , arg2); 
myFrag. setArguments (args) ; 
return myFrag; 

} 

Ora invocando semplicemente il metodo getMyFragment ( ) e passando i valori per i parametri 
essenziali, otteniamo direttamente il riferimento all'oggetto completato. Chi utilizza tale oggetto non ha 
il dubbio che lo stesso non sia consistente. Nel caso specifico utilizziamo il metodo setArguments ( ) 
per salvare tali parametri all'interno di un oggetto di tipo Bundie che il sistema ci consenterà di 
preservare anche a seguito di riawii dovuti alle eventuali rotazioni o comunque a variazioni dei 
parametri di configurazione. È buona norma che i fragment definiscano tali valori attraverso delle 
costanti statiche da utilizzare come valori per le relative chiavi Attenzione: il fragment è stato creato 
ma non è stato aggiunto ad alcun layout, cosa che dovrà quindi avvenire in modo esplicito attraverso 
unFragmentManager, come vedremo successivamente. 

Il secondo metodo di creazione di un fragment consiste nell'utilizzo dell'elemento |fragment/> 
all'interno del layout che lo dovrà contenere. Attraverso l'attributo name è possibile quindi specificare 
il nome completo della classe che lo descrive. Qui il fragment viene istanziato attraverso il proprio 
costruttore di default, quindi la sua eventuale UI verrà aggiunta al componente che lo contiene, che 
dovrà presumibilmente essere un layout o comunque una specializzazione della classe viewGroup. Nel 
caso in cui fossero presenti più elementi <f ragment/> dotati diUI si avrebbe l'aggiunta delle 
corrispondenti view nello stesso ordine in cui sono stati definiti come nel seguente esempio di 
documento di layout: 

<?xml version="l . 0" encoding="ut f-8 " ?> 

<LinearLayoutxmlns : android="http : / / schema s . andrò id . corri/ apk/ res/android" 
android : orientation="horizontal " 
android: layout_width="match_parent " 
android: layout_height="match_parent "> 

<f ragment android: name="com. example . news . ArticleListFragment " 

android: id=" @+id/list " android: layout_weight=" 1 " 

android: layout_ android: layout_heìght="match_parent " /> 
<f ragment android: name="com. example . news . ArticleReaderFragment" 

android: id="@+id/viewer" android: layout_weight="2" 

android: layout_ android: layout_height="match_parent "/> 
</LinearLayout> 

Un aspetto di fondamentale importanza riguarda la modalità con cui un fragment debba poi essere 
referenziato dal sistema e questo può avvenire in due modi diversi: 

• attraverso l'utilizzo di un id intero: 

• attraverso l'utilizzo di un tag di tipo String: 

Si tratta di informazioni fondamentali che il sistema stesso utilizza al fine di preservare lo stato del 
componente dopo una rotazione del display oppure dell'eliminazione dell'attività che li contiene a 
seguito di una richiesta impellente di risorse. 

Nell'esempio precedente i due fragment erano caratterizzati da un id, soluzione che è la scelta 
standard nel caso in cui vi sia una UI da visualizzare. In alcuni casi, come vedremo in un successivo 
esempio, questo non avviene, per cui serve un meccanismo alternativo che è appunto quello del tag, 
che è sostanzialmente un nome. Nel caso in cui non si fornissero valori per Pid o per il tag (cosa 
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sconsigliata), il sistema ne utilizzerà di propri 

La fase successiva nella vita di un fragment è quella che lo lega all'activity che lo contiene. Esso 
viene infatti "attaccato" a tale activity e questo viene notificato attraverso l'invocazione del metodo 

public void onAttach (Activity activity) 

che permette al fragment di ottenere un riferimento all'attività in quanto tale o perché dotata di 
alcuni metodi implementati da una particolare interfaccia di callback, come visto nell'esempio 
precedente e come vedremo nel nostro progetto. 

È importante precisare che in questa occasione si ottiene un riferimento a un'attività che non è 
comunque ancora completamente inizializzata; questo significa che non potremo accedere a quelle 
componenti inizializzate nel corrispondente metodo oncreate o . 

La fase successiva consiste quindi nell'invocazione del seguente metodo: 

public void onCreate (Bundle savedlnstanceState) 

È un metodo con funzionalità analoghe all'omonimo per le attività e rappresenta un buon punto in 
cui eseguire delle operazioni di inizializzazione oltre che gestire lo stato attraverso il parametro 
savedlnstanceState; mentre per le attività questo è anche il metodo di inizializzazione del layout, per 
i fragment è stato deciso di delegare tale funzione a un altro metodo di callback e precisamente: 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, Bundle 
savedlnstanceState) 

La responsabilità di questo metodo sarà quindi quella di ritornare la particolare specializzazione di 
view che caratterizzerà il layout del nostro fragment. Per fare questo il sistema ci fornisce il riferimento 
al Layoutinf later per la creazione della view da un documento di layout. 

Come vedremo nel dettaglio successivamente non tutti i fragment dovranno disporre di un layout, 
mentre altri avranno dei layout predefiniti come il ListFragment e il DiaiogFragment. 

Come nel metodo oncreate ( ) , anche qui viene passato il riferimento a un Bundle che potrà essere 
utilizzato per l'accesso all'eventuale stato salvato in precedenza. L'esistenza di questo metodo in 
qualche modo giustifica la non avvenuta inizializzazione dell'attività collegata che necessitava anche del 
layout del fragment. 

Il metodo di notifica dell'avvenuta conclusione del metodo oncreate ( ) da parte dell' activity è il 
seguente: 

public void onActivityCreated (Bundle savedlnstanceState) 

Esso contiene nuovamente come parametro il riferimento al Bundle con le eventuali informazioni di 
stato precedentemente salvate secondo la modalità che vedremo nei prossimi paragrafi. 

Un aspetto forse non ovvio del ciclo di vita di un fragment è che la sua creazione non corrisponde 
necessariamente all'invocazione dei metodi precedenti, che sono comunque conseguenza della loro 
aggiunta alla gerarchia associata all'activity contenitore. Quando viene richiesta la visualizzazione di un 
fragment, esso segue un procedimento analogo all'activity ovvero sia ha l'invocazione del metodo di 
callback: 

public void onStart () 

in corrispondenza della visualizzazione della UI associata e quindi del metodo: 

public void onResumet) 

quando tale UI diventa attiva e quindi consente all'utente di interagire con essa. In questo momento 
il fragment è attivo e il proprio layout, se presente, è parte del layout visualizzato dall' activity 
contenitore. 

A questo punto può succedere che, dopo un'azione dell'utente, un fragment venga rimosso dalla 
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UI correntemente visualizzata per l'aggiunta, per esempio, di un altro con un dettaglio maggiore di 
informazioni In questo caso è bene ricordare che l'attività contenitore resta comunque attiva, mentre 
il fragment passerà prima nello stato di paused e quindi stopped. È un passaggio di cui riceveremo 
notifica attraverso l'invocazione, da parte del sistema, dei due metodi di callback 

public void onPauset) 

e 

public void onStopO 

Abbiamo quindi capito che, mentre quando l'attività contenitore passa nello stato di paused e poi 
stopped, tutti i fragment contenuti seguono lo stesso flusso, il contrario non è vero. Un fragment può 
arrivare nello stato stopped anche se l'attività è ancora nello stato active. 

Nella Figura 4.6 questo passaggio è descritto a seguito di due casi distinti che si differenziano per 
l'aggiunta o meno a quello che prende il nome di back stack. Come detto all'inizio, la navigazione tra 
attività è diversa dalla navigazione tra fragment. Nel secondo caso si potrebbe avere la necessita di 
memorizzare un insieme di transizioni per poter poi "tornare indietro". L'insieme dei passi relativi 
all'aggiunta, rimozione o sostituzione di fragment può essere memorizzato all'interno di imo stack per 
poi gestire il ritomo attraverso la pressione del pulsante Back. 

In ogni caso, quando il fragment è nello stato di stopped, il sistema può decidere di rilasciare le 
relative risorse eliminando la gerarchia delle view associata. La notifica di questo si ha attraverso 
l'invocazione del metodo 

public void onDestroyView ( ) 

la quale avviene dopo che l'eventuale stato del fragment è stato salvato. Come evidenziato nella 
Figura 4.6, una nuova visualizzazione a seguito del ripristino o della pressione del pulsante Back 
quando il fragment era nel corrispondente stack provocherà ima nuova invocazione del metodo di 
creazione della view, ovvero oncreateview ( > . 

La vita di un fragment si conclude attraverso l'invocazione del metodo 

public void onDestroyO 

e infine di 

public void onDetach() 

che "stacca" il fragment dalla corrispondente attività. Questi due metodi saranno l'occasione per 
eliminare e rilasciare tutte le risorse utilizzate al fine di un loro buon riutilizzo da parte di altri 
componenti della stessa applicazione. 

Utilizzo di FragmentManager e FragmentTransaction 

Abbiamo quindi visto come un fragment sia sostanzialmente un componente, dotato di UI o meno, 
da utilizzare per comporre le funzionalità delle nostre activity a cui devono comunque essere 
associate. Per semplificarne la gestione, le API di Android ci mettono a disposizione un oggetto 
descritto dalla classe FragmentManager, che permette sostanzialmente di gestire i vari fragment e il 
relativo back stack. È importante sottolineare come esistano due diverse modalità con cui si ottiene 
un riferimento a questo utile componente (che ricordiamo essere disponibile solamente dalla versione 
3.0 - API Level 11 - della piattaforma). La prima è quella classica che prevede, appunto per i 
dispositivi di Api Level Ilo superiore, la semplice invocazione del metodo 

FragmentManager f ragmentManager = getFragmentManager ( ) ; 

ereditato dalla classe Activity. Per le versioni precedenti occorre invece utilizzare la 
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Compatibility Library, che viene aggiunta automaticamente a ogni progetto creato conAndroid 
Studio nella modalità descritta ormai un paio di volte. 

NOTA 

La Compatibility Library non consente solamente l'utilizzo dei fragment ma anche di altri utili librerie 
come i Loaders e la nuova gestione delle notifiche fin dalla versione 1.6 della piattaforma. Le classi 
di questa libreria sono in genere omonime alle corrispondenti della piattaforma ma in un package 

diverSO del tipO androìd.support . v4 . app. 

Nelle versioni precedenti il metodo getFragmentManager ( ) non è disponibile per cui si rende 
necessario che le nostre activity estendano una classe di nome FragmentActivity, la quale ci 
permette di ereditare invece questo metodo: 

android. support . v4 . app . FragmentManager f ragmentManager = getSupportFragmentManager ( ) 

Il nome del package dell'oggetto ritornato è relativo alle classi della Compatibility Library. Da 
questo punto in poi le due implementazioni possono essere utilizzate allo stesso modo per cui non 
faremo distinzione tra le due se non nel caso di bisogno. 

Un primo aspetto gestito da questo oggetto riguarda i fragment creati e la possibilità di ottenerne un 
riferimento attraverso il suo id o il tag. A tal proposito esistono i seguenti due metodi; 

public Fragment f indFragmentByld (int id) 
public Fragment f indFragmentByTag (String tag) 

Si tratta di metodi molto utili quando si ha la necessità di ottenere il riferimento ai diversi fragment 
per modificarne, eventualmente, le informazioni nella UI o interagire con i task che gli stessi possono 
incapsulare nel caso di assenza di interfaccia grafica. Una nota va invece fatta sulla diversa modalità 
con cui l'identificatore e il tag di un fragment vengono impostati. Questo può avvenire attraverso un 
documento XML di cui eseguire Y inflette oppure nel momento in cui il fragment viene aggiunto, come 
vedremo tra poche righe. 

Fino a qui abbiamo infatti solamente descritto come un fragment viene creato ma non come viene 
effettivamente reso attivo; abbiamo visto che questo accade automaticamente qualora si utilizzasse il 
componente <f ragment/> ma non sappiamo come questo possa avvenire se venisse creato da 
codice. Ebbene, la responsabilità di questo è di un altro fondamentale componente che prende il 
nome di FragmentTransaction, di cui si ottiene un riferimento a partire dal FragmentManager nel 
modo descritto in queste poche, ma fondamentali, righe di codice: 

FragmentTransaction f ragmentTransaction = f ragmentManager . beginTransaction () ; 

ExampleFragment fragment = new ExampleFragment ( ) ; 

f ragmentTransaction . addToBackStack ( "my frag") ; 

f ragmentTransaction . add (R. id . fragment_container, fragment) ; 

f ragmentTransaction . commi t () ; 

Innanzitutto notiamo come si ottenga una Fragment Tras action attraverso il metodo 
beginTransaction ( ) , motto esplicativo in quanto rafforza l'analogia del concetto di transazione con 
quella in un contesto più tradizionale in ambiente enterprise. Esso indica che si sta iniziando qualcosa 
che dovrà contenere un insieme di operazioni che dovranno comunque essere considerate come una 
sola, operazioni che dovranno quindi essere applicate oppure essere eliminate tutte insieme. Questo ci 
porta a pensate che debba esistere un modo per aggiungere operazioni alla transazione e questo è 
proprio quello che accade con i seguenti metodi; 

public FragmentTransaction add (int containerViewId, Fragment fragment) 
public FragmentTransaction add (Fragment fragment, String tag) 

public FragmentTransaction add (int containerViewId, Fragment fragment, String tag) 

i quali permettono di aggiungere un fragment all' activity secondo diverse modalità. La differenza 
principale è relativa alla presenza o meno di una UI. L'utilizzo del primo metodo presuppone infatti la 
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presenza di un container di cui si specifica l'identificatore. In quel caso il fragment dovrà definire una 
propria UI all'interno del metodo oncreateview ( ) . Nel caso in cui non vi fosse una UI, e quindi un 
container, si può utilizzare il secondo overload con il tag come parametro. Il terzo è un modo per 
impostare entrambe le informazioni. È bene sottolineare come il metodo add ( ) permetta l'aggiunta del 
fragment all'attività all'interno della transazione corrente e quindi non necessariamente l'aggiunta della 
sua UI all'interno di un viewGroup. 

Come detto ima transazione può contenere un numero qualunque di operazioni, tra cui anche la 
rimozione di un fragment attraverso questo metodo: 

public FragmentTransaction remove (Fragment fragment) 

Notiamo come qui vi sia come parametro il fragment da rimuovere, di cui possiamo comunque 
ottenere un riferimento, dato id o tag, attraverso i seguenti metodi della classe f ragmentManagerl 

public Fragment f indFragmentByld (int id) 
public Fragment f indFragmentByTag (String tag) 

Utilizzando i metodi 

public FragmentTransaction replace (int contaìnerViewId, Fragment fragment, String tag) 
public FragmentTransaction replace (int contaìnerViewId, Fragment fragment) 

possiamo invece aggiungere alla transazione un' operazione che consiste sostanzialmente nel 
rimuovere un fragment precedentemente aggiunto sostituendolo con uno nuovo. Prima di procedere 
oltre possiamo osservare come si tratti di metodi che ritornano un'istanza dell'oggetto stesso al fine di 
semplificare il codice attraverso un meccanismo che si chiama di chaining. 

NOTA 

La modalità di chaining consente di semplificare la scrittura del codice attraverso istruzioni del tipo 

obj.metodol (} .metodo2 {) .metodo3 () ed è molto utile specialmente se utilizzata insieme allo static factory 
method. 

Quando tutte le operazioni sono state registrate all'interno della transazione si deve invocare il 
metodo commit ( ) , che la rende effettiva. In realtà le operazioni di ima transazione non vengono 
applicate immediatamente ma vengono accodate tra quelle da eseguire nel thread responsabile della 
gestione della UI, che prende il nome di thread principale o UI Thread. 

NOTA 

Nella realtà è qualcosa che non accade spesso, ma nel caso in cui si avesse l'esigenza di eseguire 
immediatamente la transazione, si può invocare, comunque dal thread principale, il metodo 

executePendìngTransactions () . 

Il raggruppamento di una serie di operazioni all'interno di un'unica transazione ha come vantaggio 
la possibilità di poter, in un certo senso, tornare indietro annullandone l'effètto. Questo non avviene 
automaticamente ma deve essere esplicitato attraverso l'invocazione del metodo: 

public FragmentTransaction addToBackStack (String name) 

il quale inserisce la transazione stessa all'interno del back stack, con il quale si può interagire in 
diversi modi tra cui semplicemente premendo il pulsante Back. Se quindi una transazione è stata 
inserita nel back stack, sarà possibile tornare allo stato precedente, semplicemente premendo il 
pulsante Back. Nel caso in cui si richiedesse un'interazione più fine, lo stesso FragmentManager ci 
permetterebbe di ottenere lo stesso effètto invocando uno dei seguenti overload del metodo 

popBackStack ( ) '. 
public void popBackStack () 

public abstract void popBackStack (String name, int flags) 
public abstract void popBackStack (int id, int flags) 

Analogamente a quanto detto relativamente all'invocazione del metodo commit ( ) , anche qui il 
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ripristino dello stato precedente viene accodato come operazione da eseguire nel thread principale. 
Per un'interazione diretta sono stati creati analoghi overload del metodo, che si chiama però 
popBackStack Immediate O e che dovrà essere eseguito comunque nello UIThread. Prima di 
dedicarci a un esempio molto importante nel prossimo paragrafo, concludiamo osservando la 
presenza del metodo 

public void addOnBackStackChangedListener 

(FragmentManager . OnBackStackChangedListener listener ) 

che ci consente di registrare un listener degli eventi legati all'aggiunta o rimozione di una transazione 
al back stack per l'esecuzione di operazioni correlate. 

Abbiamo visto come attraverso il f ragmentManager Sia possibile decidere il ciclo di vita dei diversi 
fragment dell'applicazione le cui modifiche possono essere registrate attraverso il concetto di 
Fragment Trans action. Nel prossimo paragrafo vedremo un esempio concreto di fragment che non 
dispone di una UI e che permetterà di affrontare anche il tema della gestione dello stato. 

Realizzazione di un fragment senza UI e la gestione dello 

stato 

Al lettore potrebbe risultare alquanto strano che un fragment possa non essere dotato di una 
propria UI da inglobare come parte del layout dell' activity che lo contiene. In effetti le motivazioni che 
hanno portato alla definizione dei fragment erano quelle di riutilizzare componenti comuni alle 
app Reazioni per smartphone e tablet che si differenziavano solamente per il layout e quindi per la loro 
disposizione sul display. In realtà i progettisti di Google hanno voluto risolvere un problema che era 
abbastanza comune e che possiamo vedere attraverso una semplice applicazione che abbiamo 

chiamato LostThreadTest. 
NOTA 

Questa applicazione contiene concetti molto importanti di gestione dei thread a cui qui 
accenneremo solo, ma che vedremo nel dettaglio nel Capitolo 9 dedicato appunto ai servizi e al 
multithreading. 

È un' app Reazione che consente la visuaRzzazione del valore di un contatore, che viene incrementato 
aR' Ritemo di un thread creato nel metodo oncreate o deU' attività, avviato nel metodo onstart o e 
quindi fermato Ri corrispondenza del metodo onstop ( ) . Il codice rektivo è molto sempRce, anche se 
presenta un problema non Ridifferente: 

public class MainActivity extends Activity { 
private int mCounter; 
private TextView mOutput; 
private CounterThread mCounterThread; 
@Override 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 
mOutput = (TextView) findViewByld (R . id. output ) ; 
mCounterThread = new CounterThread ( ) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 
mCounterThread . start ( ) ; 

} 
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@Override 

protected void onStopO { 
super . onStop ( ) ; 
mCounterThread . stopCounter ( ) ; 

} 

public class CounterThread extends Thread { 
private boolean mRunner = true; 
SOverride 

public void run() { 
while (mRunner) { 

try { Thread . sleep (500L) ; } catch ( InterruptedException ìe) { } 
mCounter ++; 

runOnUiThread (new RunnableO { 
@Override 

public void run ( ) { 

mOutput . setText ( "Counter : " + mCounter) ; 

} 




public void stopCounter ( ) { 
mRunner = false; 

} 

} 

} 

Consigliamo al lettore di avviare l'applicazione osservando come, in effetti, il contatore venga 
incrementato e quindi visualizzato nel display. Il problema si presenta in corrispondenza della 
rotazione del dispositivo, che sappiamo provocherà il riavvio dell' activity con successiva distruzione 
del thread che verrà creato nuovamente ripartendo dal valore 0. 

NOTA 

La rotazione dell'emulatore è possibile attraverso la pressione di alcuni tasti che dipendono dal 
sistema operativo utilizzato. Su Mac è sufficiente premere Fn+Ctrl+F12, mentre su Windows è 
sufficiente premere i tasti Ctrl+F11 o Ctrl+F12. 

Nel caso delle activity abbiamo già visto nel capitolo precedente come risolvere questo problema 
salvando e quindi ripristinando il valore del contatore, che poi viene impostato come valore iniziale di 
un nuovo thread che ne riprende il conteggio. Nel nostro esempio abbiamo implementato questa 
soluzione nel seguente codice precedentemente commentato: 

private statìc final String COUNTER_EXTRA = 

"uk . co .massimocarli . android. lostthreadtest . extra . COUNTER_EXTRA" ; 

@Override 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 
if (savedlnstanceState != nuli) { 

mCounter = savedlnstanceState . getlnt (COUNTER_EXTRA, 0); 

} 

mOutput = (TextView) findViewByld (R. ìd. output) ; 
mCounterThread = new CounterThread () ; 

} 

@Override 

protected void onSavelnstanceState (Bundle outstate) { 
super . onSavelnstanceState (outstate) ; 
outstate .putlnt (COUNTER_EXTRA, mCounter) ; 



156 



> 

Con questa modifica è semplice verificare come il problema del contatore sia risolto anche se un 
altro fondamentale e grave limite è comunque rimasto. Proviamo infatti a lanciare l'applicazione, 
premere il pulsante di spegnimento del display e per poi riaccenderlo successivamente. Il risultato sarà 
il crash dell'applicazione dovuto al fatto che il thread creato nel metodo oncreate ( ) viene ora avviato 
due volte, cosa che nel nostro caso è sbagliata per due ragioni La prima è che un thread che ha 
terminato il suo scopo, e quindi l'esecuzione del metodo mno, non può più essere avviato. La 
seconda è che in ogni caso non possiamo invocare due volte il metodo start ( ) , che va invocato solo 
su thread appena creati 

A parte questi problemi comunque critici l'intenzione era quella di avviare un nuovo thread per 
continuare il lavoro del thread precedente, cosa non sempre possibile. L'ideale sarebbe avere una 
zona franca per il thread in modo che possa continuare la propria vita e il proprio lavoro anche se 
l'attività che lo contiene viene riavviata a seguito di una rotazione o comunque di ima variazione di un 
fattore di configurazione. 

NOTA 

Per non lasciare le cose al metà suggeriamo al lettore di risolvere il problema precedente come 
esercizio. Che cosa succede se spostiamo la creazione del thread dal metodo oncreate <> al metodo 

onStart () ? 

Come soluzione abbiamo creato il progetto NouiFragmentTest, che descriviamo nelle parti 
essenziali iniziando all'activity che ora è molto semplice, poiché molta della logica da noi voluta è 
incapsulata nel fragment descritto dalla classe CounterFragment! 

public class MainActivity extends FragmentActivity implements CounterListener { 

private TextView mOutput; 
SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 
mOutput = (TextView) findViewByld (R . id . output ) ; 
if (savedlnstanceState == nuli) { 

Fragment fragment = new CounterFragment ( ) ; 
//fragment . setRetainlnstance (true) ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 
.add(R.id. container, fragment) .commit(); 

} 

} 

SOverride 

public void count (final int countValue) { 

runOnUiThread (new Runnable ( ) { 

SOverride 

public void run ( ) { 

mOutput . setText ( "Counter : " + countValue); 

} 

}) ; 

} 

} 

La nostra classe estende FragmentActivity e quindi può essere utilizzata anche inversioni 
precedenti la 3.0 gestite dalle Compatibility Library. Dopo l'impostazione del layout non facciamo 
altro che creare un'istanza di CounterFragment e quindi aggiungerla attraverso una transazione al 
contenitore identificato dalla costante R. id. container e definita nel layout. Notiamo come l'utilizzo 
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del chaining ci permetta di avere del codice molto limitato. 

Un aspetto invece non evidente è legato al perché il fragment non venga aggiunto a ogni 
invocazione del metodo oncreate ( ) , ma solamente nel caso in cui l'oggetto Bundie di nome 
savedinstancestate sia nuli. Questo succede perché le activity considerano gli eventuali fragment 
aggiunti nel modo descritto come facenti parte del proprio stato, e quindi li salvano in un oggetto di 

tipo Bundle. La nostra attività implementa quindi 1'ÌnterfaCCÌa CounterFragment.CounterListener 

come meccanismo che la ricezione del valore da visualizzare da parte del fragment. Dobbiamo 
comunque fare molta attenzione. Per capirne il motivo abbiamo creato ilcounterFragment descritto 
da questo codice: 

public class CounterFragment extends Fragment { 
public interface CounterListener { 
void count (int countValue) ; 

} 

private int mCounter; 

private CounterThread mCounterThread; 
private CounterListener mCounterListener; 
@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
mCounterThread = new CounterThread () ; 
mCounterThread . start ( ) ; 

} 

@Override 

public void onDestroyO { 
super . onDestroy ( ) ; 
mCounterThread . stopCounter ( ) ; 

} 

SOverride 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 

if (activity instanceof CounterListener) { 

mCounterListener = (CounterListener) activity; 

} 

} 

@Override 

public void onDetach() { 
super . onDetach ( ) ; 
mCounterListener = nuli; 

} 

public class CounterThread extends Thread { 
private boolean mRunner = true; 
@Override 

public void run() { 
super . run ( ) ; 
while (mRunner) { 

try { Thread. sleep (500L) ; } catch ( InterruptedException ìe) { } 
mCounter ++; 

if (mCounterListener != nuli) { 

mCounterListener. count (mCounter) ; 

} 

} 
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} 

public void stopCounter ( ) { 
mRunner = false; 

} 

} 

} 

Possiamo osservare come si tratti di un fragment senza UT, che quindi non avrà un output ma 
notificherà, attraverso l'interfaccia CounterListener, il valore del contatore all'attività. A tale 
proposito vediamo come l'attività non si registri in modo esplicito come listener ma di come il tutto 
avvenga durante l'invocazione dei metodi onAttach ( ) e onDetach ( ) . Notiamo infine come il 
counterThread, non molto diverso da quanto già visto, venga avviato nel metodo oncreate o e quindi 
fermato nel metodo onDestroy ( ) . Non ci resta che eseguire la nostra applicazione ripetendo lo stesso 
esperimento della rotazione. 

Come il lettore potrà constatare il funzionamento non è cambiato di molto se non per un aspetto 
comunque importante legato al precedente errore del doppio avvio delthread. Ora la rotazione 
dell' activity porta all'invocazione dei metodi oncreate ( ) e poi onDestroy ( ) anche sul fragment. Il 
problema della persistenza del valore corrente del contatore potrebbe essere risolto in un modo 
analogo a quanto fatto per le activity e quindi implementando il codice in precedenza commentato: 

private static final String COUNTER_EXTRA = 

"uk . co .massimocarli . android . nouif ragmenttest .extra . COUNTER_EXTRA" ; 

@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
if (savedlnstanceState != nuli) { 

mCounter = savedlnstanceState . getlnt (COUNTER_EXTRA, 0); 

} 

mCounterThread = new CounterThread () ; 
mCounterThread . start () ; 

} 

QOverride 

public void onSavelnstanceState (Bundle outState) { 
super . onSavelnstanceState (outState) ; 
outState . putlnt (COUNTER_EXTRA, mCounter ) ; 

} 

Quanto fatto con l'utilizzo del fragment potrebbe quindi sembrare inutile se non fosse per 
l'esistenza del seguente metodo: 

public void setRetainlnstance (boolean retain) 

Passando un valore true a un fragment che non è nel back stack significa dire al sistema che lo 
stesso non deve essere distrutto e quindi ricreato a seguito del riavvio dell' activity che lo contiene per 
una modifica di configurazione o altra situazione di riavvio e ripristino. Questo significa che i metodi 
oncreate ( ) e onDestroy ( ) non vengono invocati ma viene mantenuto il flusso compreso tra il metodo 
onAttach ( ) e onDetach ( ) . Nel nostro caso, l'attivazione di questa opzione, renderà superflua la 
gestione dello stato all'interno del Bundle in quanto non si avrà alcuna distruzione e quindi ripristino. 
Ecco che semplicemente decommentando tale istruzione nel nostro codice: 

@Override 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_main) ; 
mOutput = (TextView) findViewByld (R. ìd. output) ; 
ìf (savedlnstanceState == nuli) { 

Fragment fragment = new CounterFragment ( ) ; 

fragment . setRetainlnstance (true) ; 
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getSupportFragmentManager ( ) . beginTrans action ( ) . add (R . id . container , 
fragment) . commit () ; 
} 

} 

la nostra applicazione manterrà in vita il thread che potrà eseguire il proprio task. Lasciamo quindi 
al lettore la prova di quanto descritto osservando attentamente il ciclo di vita dei fragment attraverso i 
relativi messaggi di log. Successivamente vedremo come questa tipologia di fragment possa essere 
usata per l'accesso ai servizi di login e registrazione. 

Comunicazione tra fragment e activity 

Sebbene siano state già utilizzate negli esempi precedenti, è bene dedicare qualche riga alla 
modalità con cui i diversi fragment e F activity contenitore collaborano tra loro. Innanzitutto ricordiamo 
che ogni fragment dispone del metodo 

public final Activity getActivity ( ) 

che viene spesso utilizzato per sfruttare il fatto che un' activity è comunque un Context. In questo 
modo si ottiene però un riferimento che non ci permette di accedere ai metodi specifici di una nostra 
activity. Una prima soluzione a questo piccolo problema consiste nel creare una variabile di istanza del 
tipo specifico della nostra attività, che quindi andiamo a inizializzare all'interno del metodo 

onAttach ( ) '. 

private MyActivity mActivity; 
SOverride 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 
mActivity = (MyActivity) activity; 

} 

In questo modo, attraverso il riferimento di tipo specifico mActivity, possiamo accedere ai metodi 
specifici ma siamo comunque legati a una particolare attività. Nel caso in cui si volesse riutilizzare uno 
stesso fragment per attività diverse, la soluzione è quella utilizzata in precedenza, ovvero la definizione 
di un'interfaccia di callback che viene implementata dalla nostra activity. Per rendere questa 
implementazione opzionale eseguiamo anche un test del tipo 

@Override 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 
if (activity instanceof Callback) { 
mCallback = (Callback) activity; 

} 

} 

che è spesso la soluzione migliore. 

Applicazione UGHO con fragment 

Dopo aver visto nel dettaglio che cosa sono e come funzionano i fragment, vediamo di utilizzarli 
all'interno della nostra applicazione UGHO, che dovrà avere un layout che si adatta al display di uno 
smartphone oppure a quello di un tablet. A dire il vero la nostra applicazione, per come è fatta ora, 
non si presta molto ad avere un layout diverso per i tablet in quanto non ci sono ancora liste con i 
corrispondenti dettagli come nell'esempio precedente. Quello che faremo in questa fase è allora un 
disaccoppiamento tra le diverse activity e i corrispondenti fragment per la parte iniziale della 
navigazione, per poi utilizzare dei fragment senza la UI per le operazioni di login e registrazione che al 
momento simulano solo delle connessioni remote. 
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La prima attività da considerare sarebbe quella relativa alla splash, la quale comunque occupa di 
solito l'intero display sia nel caso di smartphone che nel caso dei tablet. Per questo motivo la 
lasciamo esattamente com' è. Per mantenere un po' di ordine eseguiamo un' operazione di 
refactoring, che prevede lo spostamento delle classi relative alle attività proprio in un package di 
nome activity (sempre relativo a quello dell'applicazione) e la creazione di un altro package che 
chiamiamo f ragment e che conterrà appunto tutte le eventuali classi specializzazioni dei fragment. Per 
tare questa operazione il nostro IDE ci viene in aiuto, per cui dovremo semplicemente creare i due 
nuovi package e quindi trascinare con il mouse le classi delle attività nella nuova posizione. Sarà cura 
del tool modificare anche i riferimenti nel file AndroidManif est . xml. Passiamo poi alla trasformazione 
dell'attività descritta dalla classe FirstAccessActivity e che contiene itre pulsanti per decidere la 
modalità di accesso all'applicazione. Da quanto abbiamo imparato nei paragrafi precedenti, ora 
l'attività non dovrà far altro che istanziare e visualizzare un fragment, che descriveremo attraverso la 
classe Fir s t Acce ssF ragment, che notificherà all'attività stessa la scelta fatta attraverso un'opportuna 
interfaccia di callback. I tre pulsanti non saranno più relativi al layout dell' activity ma a quello del 
corrispondente fragment. 

Come per le activity, il primo passo consiste il più delle volte nella creazione del corrispondente 
documento di layout. Nel nostro caso il documento esisteva già e si chiama activity_main . xml. 
Abbiamo usato il passato perché ora questo stesso documento sarà contenuto nel file di nome 

f ragment_main . xml. 

NOTA 

Non c'è nulla di formale ma è bene fare in modo che il nome di un layout richiami in qualche modo, 
e dove possibile, il tipo di componente che lo andrà a utilizzare. 

Il file activity_main . xml non ci serve più poiché l'attività farà riferimento a un documento di 
layout che utilizzeremo in più punti perché consente l'inserimento di un unico fragment, come vedremo 
tra poco. 

Il sorgente del nostro primo fragment è descritto dalla classe First Acce ssF ragment, che riportiamo 
di seguito evidenziando le parti di interesse: 

public class FirstAccessFragment android. support .v4 . app .Fragment { 
public interface FirstAccessListener { 
void enterAsAnonymous ( ) ; 
void doLogin ( ) ; 
void doRegistration() ; 

} 

private FirstAccessListener mListener; 
@Override 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 

if (activity instanceof FirstAccessListener) { 
mListener = (FirstAccessListener) activity; 

} 

} 

@Override 

public View onCreateView (Layoutlnf later inflater, 

ViewGroup container, Bundle savedlnstanceState) { 
final View f irstAccessView = inf later. inf late (R. layout. fragment_main, nuli); 
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f irstAccessView . f indViewByld (R . id . anonymous_button) 
. setOnClickListener (new View . OnClickListener ( ) { 

@Override 

public void onClick (View view) { 
if (mListener != nuli) { 

mListener . enterAsAnonymous ( ) ; 

} 

} 

}); 

f irstAccessView. f indViewByld (R. id. login_button) 
. setOnClickListener (new View . OnClickListener ( ) { 

SOverride 

public void onClick (View view) { 
if (mListener != nuli) { 
mListener . doLogin ( ) ; 

} 

} 

}) ; 

f irstAccessView. f indViewByld (R. id. login_button) 
. setOnClickListener (new View . OnClickListener ( ) { 
SOverride 

public void onClick (View view) { 
if (mListener != nuli) { 

mListener . doRegistration ( ) ; 

} 

} 

}) ; 

return f irstAccessView; 

} 

gOverride 

public void onDetach ( ) { 
super . onDetach ( ) ; 
this .mListener = nuli; 

} 

} 

Innanzitutto vediamo come il nostro fragment estenda l'omonima classe del package relativo alla 
Compatibiliy Library, cioè android . support . v4 . app Di seguito abbiamo quindi definito 
un'interfaccia interna che descrive le operazioni che un listener delle azioni sul fragment dovrà 
implementare per gestire la selezione da parte dell'utente. La presenza di questa interfaccia non è 
accompagnata da un corrispondente metodo setxxx ( ) in quanto ci si aspetta che il listener sia 
l'activity di cui otteniamo un riferimento all'interno dell'implementazione del metodo onAttach ( ) . Al 
termine di questo metodo di callback, la variabile mListener conterrà il riferimento all'activity 
contenitore, che dovrà quindi implementare i metodi di selezione nei quali gestire gli eventi 
analogamente a quanto faceva in precedenza. Nel codice del fragment non dovrebbe quindi esserci 
più alcuna parte oscura, per cui passiamo all'implementazione dell'attività, che ora è leggermente più 
snella in quanto non contiene la gestione della UI. La parte di interesse al momento è solamente 
questa: 

public class FirstAccessActivity extends FragmentActivity 

implements FirstAccessFragment . First AccessListener { 

SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_single_f ragment) ; 
if (savedlnstanceState == nuli) { 

final FirstAccessFragment fragment = new FirstAccessFragment () ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 

. add (R . id . anchor__point , fragment ) . commit ( ) ; 
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} 

} 



L'utilizzo della Compatibility Library ci ha costretto a estendere la classe hragmentActivity, 
mentre per ascoltare gli eventi dal fragment abbiamo implementato l'interfaccia 
FirstAccessFragment.FirstAccessListener. Notiamo come ora l'attività utilizzi il layout per la 
gestione di un unico fragment che creiamo e aggiungiamo solamente nel caso in cui non si sia in una 
situazione di riavvio. I fragment associati a un'activity rappresentano infatti un'informazione che fa 
parte del suo stato e viene conservata in modo automatico. Se aggiungessimo ogni volta un'istanza del 
fragment noteremmo un proliferare di componenti UI che verrebbero aggiunti a ogni rotazione del 
dispositivo. Il layout è molto semplice e contiene un FrameLayout che utilizziamo come elemento di 
aggancio, come evidenziato nel seguente codice: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 
android : layout_width="match_jparent " 
android : layout_height="match_parent " 
android : id=" @+id/anchor_point " > 

< /FrameLayout > 

Osservando le UI di tutte le attività della nostra applicazione potremmo vedere come anche quella 
relativa alla scelta della funzione e quindi della categoria siamo molto simili In eflètti i fragment 
saranno praticamente uguali differenziandosi solamente per le label dei vari pulsanti La differenza 
sostanziale sarà però nel modo in cui tali fragment vengono utilizzati. Nel caso di dispositivi con 
display di grandi dimensioni implementeremo una navigazione che prevede all'inizio la visualizzazione 
di pulsanti per la scelta della funzione a sinistra e quindi il relativo dettaglio a destra. Nel nostro caso si 
tratta perlopiù di menu, per cui abbiamo deciso di implementare ima logica simile a quella nella Figura 
4.2 attraverso i fragment di selezione della categoria di domande e l'input del dato stesso. 

NOTA 

Per il momento tralasciamo la parte di login e registrazione, che richiede la conoscenza di un tipo 
particolare di fragment che descriveremo nel paragrafo successive. 

Il passo successivo è quello di creare le classi dei fragment con l'interfaccia che al momento viene 
visualizzata da queste attività: 

MenuActivity 

NewDataActivity 

InputDataActivity 

LocalDataActivity 

RemoteDataActivity 

Con un procedimento analogo a quanto fatto in precedenza realizziamo quindi le seguenti classi 

MenuFragment 
NewdataFragment 
Input DataFragment 
LocalDataFragment 
RemoteDataFragment 

che il lettore ormai dovrebbe saper leggere senza alcun problema. L'unica nota riguarda la nostra 
implementazione della classe Input DataFragment, che prevede la definizione del seguente metodo 
statico di Factory: 

public static InputDataFragment getlnputDataFragment (final String category) { 
final InputDataFragment fragment = new InputDataFragment () ; 
Bundle args = new Bundle ( ) ; 

args .putString (CATEGORY_ARG_KEY, category) ; 
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f ragment . setArguments (args) ; 

return f ragment; 

} 

che ci permette di creare un'istanza delfragment e allo stesso tempo di memorizzare l'informazione 
relativa alla categoria della domanda come argomento. A ogni fragment si può infatti associare una 
serie di informazioni incapsulate all'interno di un oggetto di tipo Bundie ( ) e memorizzate attraverso il 
metodo setArguments ( ) . In ogni istante potremo poi riottenere il valore inserito attraverso i metodi 
getxx ( ) del Bundie ottenuto attraverso il metodo getArguments ( ) , come il lettore può verificare 
all'interno del metodo Increateview o .Da notare inoltre come anche il nome dei relativi documenti 
di layout sia stato modificato sostituendo il prefisso activity_ con quello fr agment_. 

È importante comunque sottolineare come la creazione dei fragment non è alternativa a quella delle 
activity che li dovranno poi contenere. Questo è ancora più vero se pensiamo che per gli smartphone 
l'applicazione dovrà comunque funzionare come adesso per quello che riguarda la navigazione dei 
contenuti Quello che ci interessa in questo momento è quindi la creazione di un layout specializzato 
per la gestione della navigazione a partire dalla selezione della funzione del menu principale. 

Per vedere come è stata implementata la logica descritta in precedenza diamo un'occhiata alla 
classe NewDataActivity e in particolare al suo metodo oncreateo, che riportiamo di seguito 
evidenziando le righe di codice più importanti: 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_menu) ; 
mlsDouble = findViewById(R.id.right_anchor) != nuli; 

this .mUserModel = (UserModel) getlntent ( ) . getParcelableExtra (USER_EXTRA) ; 
if (mUserModel == nuli) { 

Log . w ( TAG_LOG, USER_EXTRA + " is mandatory ! " ) ; 

finish ( ) ; 

} 

if (savedlnstanceState == nuli) { 

final NewDataFragment fragment = new NewDataFragment ( ) ; 

getSupportFragmentManager () .beginTransaction () 

. add (R. id. anchor_point, fragment) . commit () ; 

final String def aultCategory = getResources (). getString (R . string . love_label) ; 

mCurrentCategory = def aultCategory ; 
} else { 

mCurrentCategory = savedlnstanceState . getString (CURRENT_CATEGORY_KEY) ; 

} 

if (mlsDouble) { 

Fragment rightFragment = 

InputDataFragment .getlnputDataFragment (mCurrentCategory) ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 

. replace (R. id. right_anchor, rightFragment) . commit () ; 

} 

} 

Innanzitutto notiamo come il layout utilizzato sia quello di nome activity_menu. Questo perché si 
tratta del layout di cui abbiamo creato un alias in corrispondenza dei dispositivi che soddisfano i 
seguenti qualificatori: 

values-sw600dp-land 
values-sw72 0dp-land 

In sostanza sono gli stessi relativi ai tablet a cui abbiamo aggiunto l'orientamento landscape 
(orizzontale). L'unica risorsa che abbiamo definito è questa: 

<resources> 

<item type="layout" 

name="actìvity_menu">@layout/ act i vi ty_double_f ragment </item> 
</ resources> 
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la quale definisce un alias di activity_menu a cui corrisponde un nuovo layout che abbiamo 
chiamato activity_doubie_f ragment e che ci consente di dividere lo schermo in due parti di cui la 
prima è metà della seconda. Il corrispondente documento di layout è il seguente: 

<?xml version="l . 0" encoding="utf-8" ?> 

<LinearLayout xmlns : android="http : / /schemas . android . com/ apk/res/ android" 
android : layout_width="match_parent " 
android : layout_height="match_parent " 
android : orientation="horizontal "> 

<FrameLayout 

android : id= " @+id/anchor_point " 

android: layout_width="match_parent " 
android : layout_weight="2 " 
android : layout_height="match_parent "> 
</FrameLayout> 

<FrameLayout 

android: id="@+id/right_anchor" 

android: layout_width="match_jparent " 
android : layout_weight=" 1 " 
android: layout_height="match_parent "> 
</FrameLayout> 
</LinearLayout> 

Possiamo osservare come si tratti sostanzialmente del layout per il singolo fragment a cui è stato 
aggiunto un nuovo punto di aggancio che abbiamo chiamato right_anchor. Il significato di questo 
nuovo punto di aggancio è quindi evidente in quanto vi inseriremo quello che assoceremo al concetto 
di dettaglio. Attraverso la variabile misDoubie verifichiamo in quale delle situazioni ci si trova. Se 
l'applicazione è in esecuzione in un tablet e l'orientamento è landscape, il layout associato 
all'identificatore activity_menu sarà, grazie all'utilizzo dei qualificatori e dell' alias, quello descritto dal 
file activity_doubie_f ragment . xml. Qui il metodo f indviewByid ( ) ritornerà un valore non nuli per 
l'identificatore r. ì d. right_anchor a differenza del caso in cui il layout selezionato fosse quello per il 
singolo fragment. Abbiamo così capito che la presenza o meno di elementi del layout ci permettono di 
riconoscerlo e di adattare di conseguenza la logica delle activity. Nel nostro caso questo ha 
ripercussioni nel secondo codice evidenziato, il quale non fa altro che visualizzare nella parte destra il 
fragment di tipo Input DataFragment associato alla categoria scelta per la domanda. Osservando il 
codice dell' activity descritta dalla classe noteremo come venga gestito lo stato della variabile 
mcurrentcategory, che ci permette di raggiungere un importante obiettivo. Supponiamo infatti di 
utilizzare l'applicazione in modalità portrait fino ad arrivare al dettaglio relativo alla categoria work. A 
questo punto ruotiamo il dispositivo. Quello che ci aspettiamo è la visualizzazione del dettaglio relativo 
al work nella parte destra nel nuovo layout. Se non salvassimo lo stato della categoria scelta nel 
modo ormai noto, non riusciremmo a fare in modo che il fragment selezionato sia quello giusto ovvero 
corrispondente alla categoria inizialmente selezionata. Come ultima cosa invitiamo il lettore a 
consultare il codice della classe inputDataActivìty, la quale dovrà essere terminata nel caso di 
orientamento landscape in modo da ritornare alla precedente NewDataActivity con il valore di 
categoria precedentemente salvato. 

In questo paragrafo abbiamo quindi realizzato una versione della nostra applicazione predisposta 
alla realizzazione di una UI ottimizzata per i tablet o comunque per dispositivi con schermo di 
dimensioni grandi quando utilizzati in posizione landscape. Se eseguita su uno smartphone il 
funzionamento dovrà essere lo stesso e corrispondere a quanto realizzato nel Capitolo 3. 

Come detto abbiamo tralasciato alcune parti dell'applicazione in quanto non eravamo ancora a 
conoscenza di due particolari tipologie di fragment che descriviamo qui di seguito e che poi 
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implementeremo nella nostra applicazione. 



ListFragment e DialogFragment 

Come avviene per le activity e come vedremo nei capitoli successivi, anche nel caso dei fragment 
esistono delle specializzazioni relative a scenari che si ripetono spesso nella realizzazione di 
un'applicazione Android. Vediamo qui come utilizzare i fragment descritti dalle classi ListFragment e 
DialogFragment attraverso un esempio descritto dal progetto DialogFragment Test. Si tratta di 
un'applicazione che ci permette sostanzialmente di verificare il funzionamento delle possibili tipologie 
di finestre di dialogo. Attraverso un ListFragment visualizziamo un elenco di opzioni. Le possibilità in 
questo caso sono associate ai diversi valori di stili e temi. Gli stili sono rappresentati dalle seguenti 
costanti 

DialogFragment . STYLE_NORMAL 
DialogFragment . STYLE_NO_TITLE 
DialogFragment . STYLE_NO_FRAME 
DialogFragment . STYLE_NO_INPUT 

mentre i temi predefiniti sono associati a questi identificatori: 

android . R. style . Theme_Holo 
android . R. style . Theme_Holo_Light_Dialog 
android . R. style . Theme_Holo_Lìght 
android . R. style . Theme_Holo_Lìght_Panel 

i quali potranno comunque essere sostituiti da opportuni terni personalizzati L'elenco delle opzioni 
è implementato nella classe MenuFragment che vogliamo estendere. ListFragment che non è altro che 
una specializzazione della classe Fragment che implementa il metodo oncreateviewo in modo da 
ritornare una gerarchia di view contenente una Listview e un altro layout da visualizzare in caso di 
lista vuota: 

public class MenuFragment extends ListFragment { 
} 

Oltre a questo, essa mette a disposizione un metodo di callback invocato in corrispondenza della 
selezione di una delle opzioni elencate. Nel nostro caso abbiamo definito una classe interna statica di 
nome MenuFragment .Menuitem a un'interfaccia interna di callback styiedDiaiogitemLìstener per la 
notifica della selezione all' activity: 

public statìc class Menuitem implements Serìalizable { 
public String styleName; 
public String themeName; 
public ìnt theme; 
public int style; 

} 

public interface StyledDialogltemListener { 
void ìtemSelected (Menuitem selectedltem) ; 

} 

Intanto osserviamo che la classe Menuitem contiene solamente attributi public, alla faccia delle 
regole sull'incapsulamento che abbiamo utilizzato in ambiente enterprise. In realtà, se non ci sono 
particolari motivi di protezione nell'accesso a questi campi, lasciarli public semplifica notevolmente il 
codice in quanto ci evita di inserire una serie di getter e setter inutili. Notiamo inoltre come si tratta di 
una classe seriaiizabie e non Parceiabie. Anche stavolta non abbiamo particolari pretese di 
prestazioni e non ci sono passaggi di oggetti tra processi diversi, per cui quello adottato è un 
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compromesso accettabile. 

Di seguito abbiamo definito l'interfaccia styiedDiaiogitemListener in linea con quanto descritto 
nel paragrafo precedente sulla comunicazione tra fragment e activity. Qui però abbiamo deciso di 
passare il riferimento allistener direttamente come parametro di un metodo statico di Factory e 
precisamente 

private StyledDialogltemListener mStyledDialogltemListener; 

public static MenuFragment getMenuFragment ( final StyledDialogltemListener listener) { 
MenuFragment fragment = new MenuFragment () ; 
fragment . setStyledDialogltemListener (listener) ; 
return fragment ; 

} 

private void setStyledDialogltemListener (final StyledDialogltemListener listener) { 
this .mStyledDialogltemListener = listener; 

} 

Essendo una specializzazione di ListFragment non dobbiamo implementare il metodo 
oncreateview ( ) ma dovremo comunque fornire un adapter attraverso il metodo setList Adapter ( ) 
ereditato. Abbiamo quindi deciso di implementare questa logica all'interno del metodo 
onActivityCreated ( ) . Nella prima parte abbiamo la creazione del nostro modello, che altro non è 
che un elenco di tutte le combinazioni possibili di temi e stili per cui andare a inizializzare un 
ArrayAdapter attraverso Yholder pattern, che ricordiamo essere un modo per tenere traccia dei 
riferimenti ai diversi componenti visuali delle righe della lista. 

SOverride 

public void onActivityCreated (Bundle savedlnstanceState) { 
super . onActivityCreated (savedlnstanceState) ; 
int[] styles = new int [ ] { DialogFragment . STYLE_NORMAL, 

DialogFragment . STYLE_NO_TITLE, 

DialogFragment . STYLE_NO_FRAME, 

DialogFragment . STYLE_NO_INPUT } ; 
int [ ] themes = new int [ ] { android . R . style . Theme_Holo, 

android . R. style . Theme_Holo_Light_Dialog, 

android . R. style . Theme_Holo_Light , 

android . R. style . Theme_Holo_Light_Panel } ; 
Stringi] styleNames = getResources ( ) 

. getStringArray (R. array . dialog_f ragment_styles ) ; 
Stringi] themeNames = getResources ( ) 

. getStringArray (R. array . dialog_f ragment_themes ) ; 
// Creazione del modello 
mModel . clear ( ) ; 

for (int i = 0; i < styles . length ; i++) { 

for (int j = 0; j < themes . length ; j++) { 
Menultem item = new Menultem(); 
item. styleName = styleNames [i] ; 
item.themeName = themeNames [ j ] ; 
item. style = styles [i] ; 
item.theme = themes [j]; 
mModel . add ( item) ; 

} 

} 

// Creazione dell 'adapter 

final ArrayAdapter<MenuItem> adapter = 

new ArrayAdapter<MenuFragment .Menultem> (getActivity ( ) , 
android . R . layout . simple_expandable_list_item_l , mModel) { 

class Holder { 

TextView themeView; 
TextView styleView; 

} 

@Override 

public View getview(int position, View convertview, ViewGroup parent) { 
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Holder holder = nuli; 

if (convertView == nuli) { 

Layoutlnf later ìnflater = Layoutlnf later . f rom (getActivity ( ) ) ; 
convertView = inflater 

. ìnf late (R . layout . layout_dialog_row, nuli ) ; 
holder = new Holder (); 

holder . styleView = (TextView) convertView. findViewByld (R. id. style_name) ; 
holder . themeView = (TextView) convertView . findViewByld (R. id. theme_name) ; 
convertView. setTag (holder) ; 
} else { 

holder = (Holder) convertView . getTag () ; 

} 

// Ottenere il valore e mostrare il risultato 
Menultem item = getltem (position) ; 
holder . styleView . setText (item. styleName) ; 
holder . themeView . setText (item. themeName) ; 
return convertView; 

} 

}; 

// Impostare l'adapter 
setListAdapter (adapter) ; 

} 

Quando un elemento della lista viene selezionato, si ha l'invocazione del seguente metodo 
anch'esso ereditato da LìstFragment: 

@Override 

public void onListltemClick (ListView 1, View v, int position, long id) { 
super . onListltemClick (1, v, position, id) ; 
ìf (mStyledDialogltemListener != nuli) { 

// Ottenere il modello 

Menultem item = mModel . get (position) ; 

mStyledDialogltemListener . itemSelected (item) ; 

} 

} 

Otteniamo così un riferimento all'oggetto del modello nella posizione selezionata e lo notifichiamo 
all'attività descritta dalla classe MainActivity, il cui metodo oncreate ( ) , come il lettore può 
osservare direttamente nel codice, non è diverso dai precedenti. Di interesse è invece 
l'implementazione del metodo dicallback: 

SOverride 

public void itemSelected ( final Menultem menultem) { 
final FragmentTransaction f ragmentTransaction = 

getSupportFragmentManager ( ) .beginTransaction ( ) ; 
Fragment previousFragment = getSupportFragmentManager ( ) 

. f indFragmentByTag (DIALOG_FRAGMENT_TAG) ; 
if (previousFragment != nuli) { 

f ragmentTransaction . remove (previousFragment ) ; 

} 

DialogFragment newDialogFragment = StyledDialogFragment 

. getStyledDialogFragment (menultem) ; 
newDialogFragment . show (f ragmentTransaction, DIALOG_FRAGMENT_TAG) ; 

} 

In corrispondenza della selezione di un elemento della lista non facciamo altro che iniziare una 
FragmentTransaction all'interno della quale rimuoviamo l'eventuale |>iaiogFragment presente 
aggiungendo quindi quello nuovo. A tal proposito abbiamo evidenziato un aspetto molto importante, 
ovvero l'utilizzo del metodo show o per l'aggiunta di un liaiogFragment a differenza di quanto 
succede con i classici fragment. Si tratta di un metodo del DialogFragment che riceve come 
parametro il riferimento alla transazione. Un lettore attento avrà inoltre notato l'assenza della chiamata 
al metodo commit ( ) . Abbiamo infatti utilizzato il metodo: 

public int show (FragmentTransaction transaction, String tag) 
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che, oltre che aggiungere ilDiaiogFragment a cui viene applicato, committa la transazione passata 
come parametro. La stessa classe mette a disposizione anche il metodo 

public void show (FragmentManager manager, String tag) 

che ha invece come primo parametro direttamente il FragmentManager. In questo caso la 
transazione viene creata automaticamente e contiene la sola aggiunta del DiaiogFragment prima di 
essere, anche qui, ''committata" automaticamente. Vediamo inoltre come il nostro 
styiedDiaiogFragment sia stato creato attraverso il metodo statico di Factory a cui abbiamo passato 
il riferimento all'attività stessa, che implementa appunto l'interfaccia styiedDiaiogListener di 
callback. 

Eccoci quindi alla classe StyiedDiaiogFragment, che notiamo estendere la classe 
DiaiogFragment, che ci fornisce due modalità distinte di definizione del contenuto della finestra di 
dialogo. La prima, utilizzata in questo esempio, consiste nell'implementazione del metodo 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, Bundle 
savedlnstanceState) 

in modo analogo a quanto si fa per un normale fragment. La seconda modalità, che vedremo 
nell'esempio successivo, consiste invece nella creazione di un oggetto Diaiog da ritornare poi 
attraverso l'implementazione del metodo 

public Dialog onCreateDialog (Bundle savedlnstanceState) 

Nel nostro esempio abbiamo quindi definito il metodo statico di Factory in modo tale da impostare 
il riferimento al Menultem selezionato nella lista che andiamo a salvare come argomento del fragment. 
Ricordiamo infatti che ogni fragment dispone di un Bundle all'interno del quale salvare le proprie 
informazioni di inizializzazione: 

public static StyiedDiaiogFragment getStyledDialogFragment (Menultem menultem) { 
StyiedDiaiogFragment fragment = new StyiedDiaiogFragment () ; 
// Creazione dell'argomento 
Bundle args = new Bundle (); 

args .putSerializable (MENU_ITEM_KEY, menultem) ; 
fragment . setArguments (args) ; 
return fragment; 

} 

Le informazioni salvate in questa fase vengono poi utilizzate in fase di creazione 
nell'implementazione del metodo: 

SOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

Menultem menultem = (Menultem) getArguments ( ) . getSerializable (MENU_ITEM_KEY) ; 
setStyle (menultem. style, menultem. theme) ; 

} 

Infine abbiamo definito il contenuto del nostro oggetto Dialog nel seguente modo: 

SOverride 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, Bundle 
savedlnstanceState) { 

View dialogLayout = inflater . inf late (R. layout . layout_dialog, container, false); 
TextView styleView = (TextView) dialogLayout . findViewByld (R. id. style_name) ; 
TextView themeView = (TextView) dialogLayout . findViewByld (R. id.theme_name) ; 
Menultem menultem = (Menultem) getArguments (). getSerializable (MENU_ITEM_KEY) ; 

styleView. setText (menultem. styleName) ; 
themeView . setText (menultem . themeName) ; 

dialogLayout . findViewByld (R. id. close_button) . setOnClickListener (new 
OnClickListener ( ) { 

@Override 
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public void onClick (View v) { 
dismiss () ; 

} 

}); 

return dialogLayout ; 

} 

Da notare come abbiamo utilizzato il metodo getArguments o per l'accesso al modello e come sia 
stato invocato il metodo dismiss o a seguito della selezione del pulsante. 

Lasciamo al lettore l'esecuzione dell'applicazione e lo studio di quali siano le diverse 
implementazioni di finestra di dialogo che possiamo utilizzare. Alcune occuperanno l'intero display e 
altre saranno solamente delle finestre fluttuanti, alcune saranno modali e altre no (Figura 4.7). 
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Figura 4.7 Esempio di un DialogFragment. 

Per esaminare la seconda modalità di creazione di un DialogFragment abbiamo realizzato il 
progetto di nome otherDiaiogFragmentTest, che contiene la creazione di due finestre molto comuni; 
la prima consente di visualizzare un messaggio in attesa di ima risposta da parte dell'utente, mentre la 
seconda permette la visualizzazione della classica animazione di caricamento o comunque di un task in 
esecuzione. In questo caso omettiamo, vista la sua semplicità, la descrizione dell'attività principale, 
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che contiene semplicemente le istruzioni per la visualizzazione delle due finestre di dialogo. La prima è 
descritta dalla classe customAiertDiaiog che estende la classe DiaiogFragment. Come già descritto, 
abbiamo definito un'interfaccia per la notifica della selezione dell'utente e un meccanismo che ci 
consente di ottenere il riferimento all'activity. Questo avviene attraverso queste definizioni; 

public interface AlertDialogListener { 
void yesPressed ( ) ; 
void noPressedt); 

} 

private OnClickListener mOnClickListener; 
SOverride 

public void onAttach (Activity activìty) { 
super . onAttach (activity) ; 

ìf (activity instanceof AlertDialogListener) { 

final AlertDialogListener listener = (AlertDialogListener) activity; 
mOnClickListener = new OnClickListener () { 

SOverride 

public void onClick (Dialoglnterf ace dialog, int which) { 
switch (which) { 
case Dialog. BUTTON_POSITIVE : 
listener. yesPressed () ; 
break; 

case Dialog. BUTTON_NEGATIVE : 

listener. noPressedO ; 

break; 
default : 

// Not managed 

break; 

} 

} 

}; 

} 

} 

Da osservare è solamente l'implementazione del metodo onAttach o nel quale otteniamo un 
riferimento all'attività come oggetto che implementa l'interfaccia AlertDialogListener, per poi 
utilizzarlo in caso di selezione del corrispondente pulsante. La creazione della finestra di dialogo 
avviene invece all'interno di questo metodo: 

@Override 

public Dialog onCreateDialog (Bundle savedlnstanceState) { 

// Crea e restituisce la finestra di dialogo AlertDìalog usando un Builder 
AlertDìalog . Builder builder = new AlertDialog . Builder (getActivity () ) 
. setlcon (R. drawable . ìc_launcher ) 
. set Ti t le (R. string . alert_dialog_title) 

. setPositiveButton (R . string . yes_label, mOnClickListener) 
. setNegatìveButton (R . string . no_label , mOnClickListener) ; 
return builder . create () ; 

} 

Possiamo notare come il codice di creazione della finestra di dialogo sia esattamente lo stesso che 
avremmo scritto in assenza del fragment che ora ne diventa il contenitore. Il risultato della nostra 
classe è quello nella Figura 4.8. 
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Figura 4.8 Creazione di una finestra di dialogo per la visualizzazione di un alert. 

Allo stesso modo abbiamo implementato la classe ProgressAiertDiaiog, il cui metodo 
onCreateDiaiog ( ) sarà questa volta il seguente: 

HOverrìde 

public Dialog onCreateDiaiog (Bundle savedlnstanceState) { 

final ProgressDialog progressDialog = new ProgressDialog (getActivity ()) ; 

progres sDi al og . setMessage (getString (R. string . loading_text ) ) ; 

progressDialog . setlndeterminate (true) ; 

progressDialog. setCancelable (false) ; 

progressDialog. setCanceledOnTouchOutside (false) ; 

progressDialog . setOnKeyListener (mOnKeyListener ) ; 

return progressDialog; 

} 

Ora l'oggetto ritornato è di tipo ProgressDialog e il risultato è quello nella Figura 4.9. 
Lasciamo al lettore la visione di come sia stata definita l'interfaccia per la notifica e quindi la 
registrazione dell' activity come listener. Degna invece di menzione è la presenza del metodo 

public void setCanceledOnTouchOutside (boolean cancel) 

per la chiusura della finestra di dialogo nel caso in cui l'utente toccasse il display in un punto 
esterno. Nel nostro caso questo non avviene avendo impostato il valore del parametro a false. 
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Lasciamo al lettore l'esecuzione di qualche esperimento in merito. Facciamo invece un' ultima 
osservazione relativamente alla modalità di creazione delle diverse finestre di dialogo, cioè quella del 

Builder. 
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Figura 4.9 Visualizzazione di una barra di avanzamento. 



Esso non è altro che l'implementazione di un famoso design pattern della GoF (Gang OfFour), 
che permette appunto di nascondere la modalità di creazione di un oggetto. 

Notiamo infatti come vengano fornite tutte le informazioni necessarie alla creazione della finestra 
per poi invocare il metodo create o . Le diverse implementazioni utilizzeranno quindi i parametri 
forniti in base alle proprie esigenze. Per esempio, se avessimo utilizzato solamente il metodo 
setPositiveButton ( ) e non il metodo setNegativeButton ( ) avremmo avuto un solo pulsante. 

Quando aggiungiamo le finestre di dialogo a UGHO? 

Alla luce di quanto visto finora ci verrebbe la tentazione di aggiungere le finestre di dialogo alla 
nostra applicazione e in effetti vi sono alcuni punti in cui la cosa sarebbe opportuna. Per esempio 
potremmo aggiungere una ProgressDiaiog in corrispondenza delle chiamate ai servizi di login e 
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registrazione, oppure aggiungere delle finestre di dialogo di avvertimento per la visualizzazione dei 
messaggi di errore nei vari forni per l'inserimento dei dati. 

In realtà abbiamo deciso di rimandare questi componenti in quanto richiedono che le operazioni di 
login e registrazione avvengano in un thread separato rispetto a quello principale di visualizzazione 
delle UI e quindi delle finestre. Vedremo comunque che si tratterà di qualcosa di davvero immediato 
specialmente alla luce dei precedenti esempi 

NOTA 

Nulla vieta al lettore di provare a integrare questi componenti già in questa fase. 

Fragment annidati 

Nella parte introduttiva di questo capitolo abbiamo giustificato la creazione di un fragment con la 
necessità di comporre delle interfacce grafiche mantenendo un certo grado di riutilizzabilità dei diversi 
componenti. Abbiamo però visto che i fragment possono essere inseriti all'interno diun'activity ma 
non all'interno di altri fragment. La possibilità di creare dei fragment come composizione di altri, è 
stata introdotta dalla versione 4.2 della piattaforma corrispondente a un API Level di 17. In realtà la 
cosa è molto semplice e si ottiene sfruttando la disponibilità del nuovo metodo: 

public final FragmentManager getChildFragmentManager () 

che ritorna un riferimento a un FragmentManager che può essere usato nella stessa modalità vista in 
precedenza; mentre prima l'oggetto ottenuto permetteva la gestione dei fragment diun'activity, ora 
esso ci consente di gestire i fragment associati a un altro fragment. Come un'attività dispone del 
riferimento alla propria activity attraverso il metodo getActivity o , ora è stato messo a disposizione 
il metodo 

public final Fragment getParentFragment () 

che permette a un fragment di ottenere il riferimento al proprio fragment contenitore. È una 
funzionalità fornita dalla Compatibility Library, che quindi può essere utilizzata da subito dalla 
versione 1.6 della piattaforma. Concludiamo infine osservando come si tratti di una funzione 
disponibile solamente a livello di codice. In sintesi non è possibile gestire questo aspetto attraverso 
l'uso dell'elemento <f ragment/>. 

Conclusioni 

In questo capitolo abbiamo fatto altri passi avanti nella realizzazione della nostra applicazione. In 
realtà non abbiamo aggiunto nuove funzionalità ma abbiamo reso l'applicazione adattabile a quelle che 
sono le caratteristiche di un tablet o comunque di un dispositivo con display di dimensioni molto 
grandi. Ricordiamo che un tablet consente non solo di avere un display più grande ma anche di 
accedere alle applicazioni in modi diversi che richiedono comunque uno studio. A parte l'introduzione 
dei concetti di fragment, in questo capitolo abbiamo voluto sensibilizzare il lettore su quanto è 
importante sfruttare al massimo i qualificatori della piattaforma per adattare il più possibile la UI di 
un'applicazione a quelle che sono le caratteristiche di un dispositivo. Come visto nel nostro progetto, 
la cosa non è sempre facile: bisogna tener conto del famigerato problema della rotazione e del 
mantenimento dello stato. E quindi importante testare l'applicazione sotto ogni punto divista. 

Dopo questi due importantissimi capitoli dedicati alle activity e ai fragment, nel prossimo inizieremo 
a vedere nel dettaglio i diversi componenti che ne caratterizzano i layout. 
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Capitolo 5 



View e layout 



Nei capitoli precedenti ci siamo concentrati principalmente nella descrizione delle modalità di 
navigazione delle schermate della nostra applicazione sia su smartphone sia su tablet. Non abbiamo 
però speso molto tempo nella descrizione di quello che le stesse schermate contenevano, ovvero i 
diversi componenti grafici. In questo capitolo cercheremo di colmare questa mancanza illustrando le 
caratteristiche principali della classe view e di una sua specifica specializzazione descritta dalla classe 
ViewGroup che è alla base della definizione di quelli che abbiamo chiamato layout. Approfitteremo di 
quanto descritto in questo capitolo per parlare anche di qualche particolare tipo di risorsa Drawable 
per la gestione degli stati caratteristici di un pulsante. Dopo aver messo in pratica il tutto sulla nostra 
applicazione, vedremo come creare dei componenti personalizzati cercando di giustificarne la 
realizzazione. 

View e layout 

Se osserviamo la UI del progetto allo stato attuale notiamo come le diverse schermate, descritte da 
altrettante activity e fragment annessi, contengano dei componenti che tipicamente sono Button per 
l'interazione con l'utente, EditText per l'inserimento di informazioni testuali e Textview per la 
visualizzazione delle stesse. Si tratta di componenti descritti da altrettante specializzazioni della classe 
view, che contiene appunto tutte le informazioni comuni a ogni elemento grafico con cui l'utente 
interagisce. Come abbiamo visto ormai più volte, l'interfaccia grafica di un'applicazione può essere 
descritta attraverso un approccio dichiarativo che prevede la definizione di documento XML che 
abbiamo chiamato documento dilayoutle che abbiamo inserito all'interno della cartella /resAayout 
delle risorse del' applicazione. L'alternativa è rappresentata da un approccio imperativo che prevede 
ima descrizione della UI attraverso delle righe di codice. Per comprendere bene quale sia la differenza 
supponiamo di voler creare una UI composta da tre pulsanti imo sopra l'altro tipica di alcune 
schermate della nostra applicazione. A dimostrazione di questi concetti consideriamo il progetto di 
nome LayoutTest nel quale chiediamo al lettore di modificare semplicemente il nome dell'attività 
principale nel file AndroidManifest .xml in corrispondenza del particolare esempio .Un approccio 
imperativo porterebbe alla creazione della seguente attività: 

public class ImperativeActivity extends Activity { 
@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

LinearLayout parentLayout = new LinearLayout (this) ; 
LinearLayout . LayoutParams lp = new LinearLayout . LayoutParams ( 

LayoutParams .MATCH_PARENT, LayoutParams . WRAP_CONTENT ) ; 
parentLayout . setLayoutParams (lp) ; 

parentLayout . setOrientation (LinearLayout .VERTICALI ; 
for (int i=0; i<3; i++) { 

Button button = new Button (this ) ; 

LinearLayout . LayoutParams buttonLp = new LinearLayout . LayoutParams ( 
LayoutParams .MATCH_PARENT, LayoutParams . WRAP_CONTENT ) ; 
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button . setLayoutParams (buttonLp) 
button.setText ("Button + ; 
parentLayout . addview (button) ; 

} 

setContentView (parentLayout) ; 



con il risultato mostrato nella Figura 5.1. 



MainActivity 




Button #0 



Button #1 



Button #2 



Figura 5.1 Layout creato in modo imperativo. 

In questo esempio abbiamo creato una gerarchia di componenti utilizzando le API dell'ambiente e 
quindi assegnato la radice di tale struttura come layout dell'attività attraverso il metodo 
setContentView ( ) . Come possiamo vedere si tratta di codice abbastanza verboso, considerata 
soprattutto la semplicità del layout che, in modo dichiarativo, risulterebbe essere così descritto dalla 

risorsa buttons_layout: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android. com/ apk/res/ android" 
android: layout_width="match__parent " 
android: layout_height="match__parent " 
android: orientation="vertical" > 



<Button 

android : id=" @+id/button0 " 

android : layout_width="match_jparent " 
android: layout_height="wrap_content " 
android: text=" @string/button_label_0 " /> 

<Button 

android : id=" @+id/buttonl " 

android : layout_width="match_jparent " 
android: layout_height="wrap_content " 
android: text=" @string/button_label_l " /> 

<Button 

android: id="@+id/button2" 

android: layout_width="match_joarent " 
android: layout_height="wrap_content " 
android: text=" @string/button_label_2 " /> 

</ Linear Layout > 

Il lettore potrebbe obiettare che anche il documento XML non sia molto sintetico ma, a differenza 
del procedente codice Java, ha diversi vantaggi, tra cui: 
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• attraverso il layout editor è possibile avere subito un feedback sul risultato; 

• sono risorse che possono essere qualificate (per esempio rispetto ai diversi orientamenti del 
display) utilizzando l'apposito meccanismo messo a disposizione dalla piattaforma; 

• aU'activity non viene data anche la responsabilità di definire l'interfaccia ma solamente quella di 
gestire gli eventi sui diversi componenti e di fungere da controller in un contesto MVC ; 

• lo stesso documento di layout potrebbe essere riutilizzato per la definizione di altre attività o 
parti di esse. 

Utilizzando il documento precedente di layout, il codice dell' activity diventa infatti molto più 
semplice e quindi più mantenibile del precedente. 
NOTA 

Model View Controller (MVC) è un pattern architetturale che consente di applicare una divisione 
delle responsabilità tra chi è dedicato alla gestione dei dati ( il Model), della loro visualizzazione (la 
VieW) e del mapping tra gli eventi sulla view e le operazioni sul Model (il Controller). È un pattern 
molto utilizzato sia in ambiente enterprise sia in ambiente mobile. 

Possiamo infatti osservare come il metodo set content view o utilizzi Yoverload, che prevede 
come parametro l'identificativo della risorsa di tipo layout che qui è data dalla costante 

R . layout . buttons_layout. 

public class DichiarativeActivìty extends Activity { 
SOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
// Impostiamo il layout 

setContentView (R . layout . buttons_layout ) ; 

} 

} 

Il risultato è lo stesso ma la classe che descrive l' activity è molto più snella e soprattutto non dovrà 
cambiare nel caso in cui dovessimo specializzare il layout in base a criteri quali l'orientamento del 
display o la relativa dimensione. 

Un lettore attento avrà sicuramente rilevato un'altra sostanziale differenza tra le due diverse 
modalità utilizzata nella definizione dei layout, ovvero la presenza (nel secondo di essi) di un 
identificatore per ciascuno dei Button. Possiamo infatti notare la presenza di una serie di attributi del 
tipo 

android: id="@+id/button2" 

che abbiamo iniziato a conoscere nel Capitolo 1 e che abbiamo evidenziato anche nel seguente 
frammento di codice del layout: 

<Button 

android : id= " @+id/button2 " 

android: layout_width="wrap_content " 
android: layout_height="wrap_content " 
android : text="@string/button_label_2 " /> 

Attraverso questo attributo abbiamo fornito ai Button un identificatore che ci permetterà di 
riconoscerli all'interno della gerarchia di componenti definita attraverso il documento XML. Per fare 
questo ogni activity eredita il metodo getViewByld ( ) che abbiamo utilizzato nell'esempio descritto 
dalla classe ReferenceActivity riportata sotto, che ci consentirà di riprendere anche altri aspetti non 
direttamente legati all'ambiente Android ma comunque molto utili 

public class ReferenceActivity extends Activity { 
// Il tag per il log 

private final static String TAG_LOG = Ref erenceActivity . class . getName () ; 
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// I riferimenti Button 
private Button mButtonO; 
private Button mButtonl; 
private Button mButton2; 



} 

Innanzitutto notiamo come la prima parte consista nella definizione di una costante statica che 
abbiamo chiamato tag_log e che utilizzeremo appunto come tag per i messaggi di log che vedremo 
all'interno della vista dieclipse di nome ìogcat. 

NOTA 

Riprendendo quanto visto nel Capitolo 1 relativamente al linguaggio Java, osserviamo come il valore 

della costante si ottenga invocando il metodo getNameO Siili OQQGttO ReferenceActivity . class. Ricordiamo 
infatti che con la sintassi <NomeClasse> . class, si fa riferimento a un oggetto di tipo Class<NomeClasse> che 
descrive appunto la classe indicata. Si tratta di un oggetto che viene spesso utilizzato come punto 
di partenza per operazioni di introspection attraverso cui è possibile scoprire le caratteristiche di 
una classe a runtime. Nel nostro caso ne otteniamo semplicemente il nome. 

Di seguito non facciamo altro che definire tre variabili locali che valorizzeremo successivamente con 
i riferimenti ai Button definiti nel layout. 

NOTA 

Le convenzioni Java relativamente alla definizione di una costante indicano che la stessa debba 
avere un nome costituito da lettere tutte maiuscole e separate dal simbolo _ (underscore) nel caso 
di più parole. Per quello che riguarda le variabili d'istanza, ovvero quelle che definiscono lo stato di 
un particolare oggetto, la convenzione prevede che il nome cominci per la lettera m seguita dal nome 
in carnei notation. Questa convenzione ha senso solamente nel caso in cui tali variabili fossero 
private. In caso contrario la m verrebbe omessa e sostituita dalla s nel caso di variabile statica (ma 
nOn final ). Nello specifico è bene dare un'occhiata all'indirizzo http://source.android.com/source/code- 

style.html. 

Nel nostro esempio siamo interessati a scoprire quale dei pulsanti venga premuto per cui definiamo 
quello che si chiama listener e che nel nostro caso è così descritto: 

private final OnCliokListener mOnCliokListener = new OnClickListener () { 

@Override 

public void onClick (View v) { 

final int buttonld = v.getld() ; 

switch (buttonld) { 
case R . id . buttonO : 

Log. i (TAG_LOG, "Button 0 Pressed"); 

break; 
case R . id . buttonl : 

Log. i (TAG_LOG, "Button 1 Pressed"); 

break; 
case R. id.button2 : 

Log. i (TAG_LOG, "Button 2 Pressed"); 

break; 
default : 

break; 

} 

} 

}; 

L'aspetto di interesse legato alla piattaforma Andro id riguarda l'utilizzo delle costanti di tipo R.id 
che sono state generate automaticamente in corrispondenza delle definizioni dei Button nel layout e 
del relativo attributo androìd: id. 
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NOTA 

Nel Capitolo 3 abbiamo realizzato la prima bozza della nostra applicazione e visto nel dettaglio il 
ciclo di vita delle activity. In quell'occasione abbiamo visto come un aspetto fondamentale riguardi il 
mantenimento dello stato di un'activity a seguito di una variazione di un elemento di configurazione 
che, nel più comune dei casi, è la rotazione del dispositivo. Ebbene, anche i componenti contenuti 
nel layout associato a un'attività dispongono di uno stato; pensiamo per esempio al testo inserito 
all'interno di un EditText. Affinché tale stato venga mantenuto è indispensabile che al corrispondente 
componente sia stato assegnato un ±d attraverso l'omonimo attributo. 

Siamo così arrivati alla descrizione del metodo oncreate ( ) , che viene invocato in corrispondenza 
della creazione dell'attività di riferimento: 

@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout .buttons_layout) ; 
mButtonO = (Button) f indViewByld (R . id.buttonO) ; 
mButtonl = (Button) f indViewByld (R . id.buttonl) ; 
mButton2 = (Button) f indViewByld (R . id . button2 ) ; 
mButtonO . setOnClickListener (mOnClickListener) ; 
mButtonl . setOnClickListener (mOnClickListener) ; 
mButton2 . setOnClickListener (mOnClickListener) ; 

} 

Possiamo notare come, dopo l'impostazione del layout attraverso il metodo letcontentvìew ( ) , 
sia stato utilizzato il metodo f indvìewByid ( ) per ottenere il riferimento a una particolare view dato il 
suo id. La necessità di ottenere questo riferimento è un ulteriore incentivo nell'assegnazione di un 
identificatore a ogni elemento dell'interfaccia. L'operazione di cast serve in quanto il metodo 
f indViewByld ( ) vale per una qualunque view che corrisponde al tipo di dato ritornato. Di seguito 
abbiamo registrato il nostro oggetto onciickListener come listener di tutti i pulsanti in modo da 
gestirne l'evento di clic. Ora non ci resta che lasciare al lettore la verifica del funzionamento della 
nostra attività modificando il file AndroidManif est . xml m modo da utilizzare l'attività descritta come 
attività principale. 

Generalizziamo il metodo findViewByld() 

Nel paragrafo precedente abbiamo visto come il metodo f indViewByld ( ) ereditato dalla classe 
Activity ci permetta di ottenere il riferimento ai nostri oggetti di tipo Button. Abbiamo inoltre visto 
come si renda necessaria l'esecuzione di un'operazione di cast, che può essere evitata attraverso la 
definizione di un paio di metodi generici di utilità definiti all'interno della classe viewutiiity. 
Osserviamo il seguente codice: 

@SuppressWarnings ( "unchecked" ) 

public statìc <T extends View> T f indViewByld (View containerView, int viewld) { 
View foundview = containerView . f indViewByld (viewld) ; 
return (T) foundview; 

} 

Come detto, si tratta di un metodo generico, ovvero che utilizza igenerìcs. E una feature molto 
importante che è stata introdotta nel' ormai lontano Java 5 e che consente sostanzialmente di creare 
quele classi type safe che abbiamo esaminato nel dettaglo nel Capitolo 1 . In questa occasione 
diciamo semplcemente che si tratta di un meccanismo che permette di definire e utilizzare dele classi 
che fanno riferimento a oggetti di tipo parametrizzato. Vediamo un semplce esempio di classe 
generica: 

public class Holder<T> { 
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private final T mObj; 



public Holder(T obj) { 
this.mObj = obj; 

} 

public T getOb j ( ) { 
return mObj; 

} 

} 

È una classe che definisce un oggetto in grado di incapsularne imo di tipo t dove t è un parametro. 
Attraverso la seguente istruzione 

Holder<String> strHolder = new Holder<String> ( "Pippo" ) ; 

abbiamo definito un oggetto di tipo Holder<String> che incapsula un riferimento di tipo string. Il 
corrispondente metodo getob j ( ) ritornerà una string e quindi sarà possibile utilizzare questa 
istruzione senza alcuna operazione di cast: 

String heldObject = strHolder . getObj () ; 

libello di queste classi è che, senza alcuna modifica, possiamo anche utilizzare le seguenti istruzioni: 

Holder<View> viewHolder = new Holder<View> (mButton) ; 
View button = viewHolder . getObj () ; 

Nel nostro metodo statico di partenza abbiamo però fàtto qualcosa di più: abbiamo indicato che il 
tipo di ritomo sarà indicato da t, che dovrà comunque essere un'istanza di una classe che estende la 
classe view. Questo è stato reso possibile dalla sintassi evidenziata 

<T extends View> 

Il corpo del metodo è ormai di semplice lettura. Ciò che invece non è evidente è l'uso che ne 
abbiamo fàtto all'interno della classe inferencedActivity. In essa abbiamo in realtà utilizzato 
quest'altro metodo 

public static <T extends View> T f indViewByld (Activity act,int viewld) { 
View containerView = act . getwindow ( ) . getDecorView ( ) ; 
return findViewByld (containerView, viewld) ; 

} 

che non fa altro che andare a prendere la view associata all'attività attraverso l'oggetto window 
associato per poi richiamare il metodo precedente. 

La nostra attività diventa ora la seguente (dove abbiamo eliminato la definizione 
dell' onciickListener e della costante tag_log per motivi di spazio): 

public class Inf erencedActivity extends Activity { 
// OnClickListener 
@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
// Impostiamo il layout 

setContentView (R . layout . buttons_layout ) ; 

// Otteniamo il riferimento dei Buttons dati i loro id 

final Button buttonO = ViewUtility . f ind.ViewById(this, R. id.buttonO) ; 

final Button buttonl = ViewUtility . findViewById(this, R . id . buttonl ) ; 

final Button button2 = ViewUtility . findViewById(this, R . id . button2 ) ; 

// Registriamo gli eventi al Button 

buttonO . setOnClickListener (mOnClickListener ) ; 

buttonl . setOnClickListener (mOnClickListener) ; 

button2 . setOnClickListener (mOnClickListener) ; 

} 

} 
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Notiamo come ora non venga utilizzata alcuna operazione di cast in quanto il tipo della particolare 
view ottenuta viene definito automaticamente attraverso quella che si chiama inferenza. Il tipo di 
ritorno del metodo statico di utilità viene definito in base al tipo della variabile a cui lo stesso viene 
assegnato. Questo significa che non avremmo problemi di compilazione neanche nel caso in cui 
avessimo questa istruzione: 

final TextView textView = ViewUtility . findViewById(this, R. id.button2) ; 

ottenendo però un errore in fase di esecuzione. Quello descritto è un semplice esempio di come i 
concetti avanzati della programmazione Java possano essere utilizzati al fine di una semplificazione del 
codice in ambito Android. 



View e ViewGroup 



In quasi tutti gli esempi descritti finora abbiamo visto come ciascuna interfaccia grafica venga 
definita attraverso una gerarchia di componenti. Alcuni di questi hanno delle responsabilità ben precise 
come ilButton e la Textview, mentre altri hanno una funzionalità che viene chiamata di layout. Essisi 
devono quindi occupare del posizionamento e ridimensionamento dei componenti al proprio intemo 
secondo delle regole particolari che sono poi quelle che li caratterizzano. Anche in questo caso non si 
tratta di nulla di nuovo se non l'applicazione di un noto design pattern che prende il nome di 
Composite e che abbiamo descritto nella Figura 5.2. 



0.. 



View 



ViewGroup 



Button 



TextView 



Figura 5.2 Pattern Composite applicato alla struttura delle view in Android. 

Come già sottolineato più volte, la classe view descrive le caratteristiche comuni a tutti i 
componenti grafici della piattaforma. Vedremo più avanti come gestire gli eventi a essi associati e 
come crearne di personalizzati Per il momento sappiamo solamente che sono componenti che 
delegano a particolari Drawable la propria renderizzazione. I diversi componenti della piattaforma 
sono descritti da classi che direttamente o indirettamente estendono la classe view come le classi 
Textview e Button più volte utilizzate e illustrate nella figura. 

NOTA 

Il lettore curioso potrà verificare come la classe Button non sia altro che una specializzazione della 
classe Textview a cui è stata data la capacità di gestire Drawable sensibili allo stato di cui vedremo 
più avanti un esempio. 

Nella figura notiamo la presenza della classe ViewGroup, che è anch'essa una specializzazione della 
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classe view ma con la fondamentale proprietà di poter aggregare altre view. Attenzione: questo 
significa che un viewGroup potrà aggregare un insieme di altre view alcune delle quali potranno essere 
a loro volta dei viewGroup che aggregano altre view e così via. Possiamo osservare come attraverso 
una struttura di questo tipo sia possibile creare un albero di componenti e poi applicare, in modo 
ricorsivo, delle operazioni a ciascuno di essi come può essere quella di visualizzazione. 
NOTA 

In realtà una relazione di aggregazione prevederebbe che uno stesso oggetto possa appartenere a 
più container, a differenza di quello che avviene in questo caso, dove una view può essere contenuta 
direttamente in un solo contenitore. 

Ma come viene rappresentata questa relazione nelle nostre applicazioni? Nel caso del codice il 
tutto viene definito in modo esplicito semplicemente creando una particolare specializzazione di 
viewGroup a cui aggiungiamo poi il contenuto attraverso il metodo addview ( ) come tatto nell'activity 
descritta dalla classe ImperativeActivityl 

LinearLayout parentLayout = new LinearLayout (this) ; 

LinearLayout . LayoutParams lp = new LinearLayout . LayoutParams ( 

LayoutParams . MATCH_PARENT, LayoutParams . WRAP_CONTENT ) ; 
parentLayout . setLayoutParams (lp) ; 

parentLayout . setOrientation (LinearLayout .VERTICAL) ; 
forfint i=0; i<3; i++) { 

Button button = new Button (this) ; 

LinearLayout . LayoutParams buttonLp = new LinearLayout . LayoutParams ( 
LayoutParams . MATCH_PARENT, LayoutParams . WRAP_CONTENT ) ; 
button . setLayoutParams (buttonLp) ; 
button. setText ("Button #"+i) ; 
parentLayout . addView (button) ; 

} 

setContentView (parentLayout ) ; 

In questo codice la particolare ViewGroup è descritta dalla classe LinearLayout, mentre il 
componente è il nostro Button. Nel caso dichiarativo la relazione di aggregazione viene definita invece 
da come gli elementi XML sono contenuti l'uno nell'altro: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android. oom/ apk/res/ android" 
android: layout_width="match_parent " 
android: layout_height="match_jparent " 
android: orientation="vertical" > 

<Button 

android: id="@+id/buttonO" 
android: layout_width="match_joarent " 
android: layout_height="wrap_oontent " 
android: text=" @string/button_label_0 " /> 

</ LinearLayout > 

Il Button è contenuto nel LinearLayout in quanto l'elemento <Button/> è contenuto nell'elemento 

<Linear Layout />. 

Descrivere la sola relazione di aggregazione non è comunque sufficiente in quanto ogni componente 
deve poter essere in grado di definire le proprie caratteristiche quali le sul dimensioni o eventuali 
margini. Per fare questo si utilizzano gli attributi del tipo 

android: layout_<nome attributo> 

È importante sottolineare come gli attributi di questo tipo che si possono associare a un particolare 
componente non dipendono dal componente stesso ma dal tipo di viewGroup nel quale lo stesso è 
contenuto. Nel precedente layout possiamo osservare che, mentre l'attributo android : text del 
Button consente di definire la label indipendentemente da dove il Button viene posizionato, 
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l'attributo android: iayout_width permette di indicare che lo stesso occuperà tutta la larghezza 
disponibile nel proprio contenitore, e questa è un'informazione che vedremo interessare il contenitore 
che qui è un LinearLayout. Vedremo successivamente come, nel caso di altri layout, si possano 
utilizzare altri attributi aggiuntivi. Come detto, ogni classe che descrive un layout viene rappresentata 
da una specializzazione della classe ViewGroup, la quale definisce a sua volta una classe interna di 

nome ViewGroup.LayoutParams che descrive gli attributi di layout. ECCO Che la classe linearLayout 

che descrive l'omonimo layout conterrà a sua volta una classe interna di nome 

Linear Layout. LayoutParams che estenderà la classe viewGroup. LayoutParams aggiungendo la 
definizione dei propri attributi. 

Posizionamento dei componenti all'interno di un layout 

Nel paragrafo precedente abbiamo visto come la responsabilità di un layout, specializzazione della 
classe ViewGroup, è quella di ridimensionare e posizionare i componenti in esso contenuto attraverso 
particolari regole che lo caratterizzano. Per quello che riguarda il posizionamento, la piattaforma mette 
a disposizione i seguenti metodi della classe View: 

public final int getLeftO 
public final int getTopO 

i quali forniscono rispettivamente la X e la Y del margine in alto a sinistra della view rispetto al 
proprio contenitore. Insieme a queste informazioni è possibile anche utilizzare i metodi; 

public final int getRightO 
public final int getBottom() 

che questa volta forniscono rispettivamente la X e la Y del vertice in basso a destra. 
NOTA 

Possiamo notare come si tratti di metodi final che non ne permettono I' override in eventuali classi 
figlie. Questo proprio per impedire che venga stravolta la logica che andremo a descrivere di seguito. 

Si tratta di informazioni che di solito si ottenevano conoscendo le dimensioni della view: 

getRight ( ) COmsponde a getLef t ( ) +getWidth ( ) 
getBottom ( ) Corrisponde a getTop ( ) +getHeight ( ) 

Queste operazioni si utilizzano all'interno di un layout per posizionare e ridimensionare i 
componenti contenuti, come faremo nell'esempio descritto dalla classe nostra classe customLayout. E 
un layout che ci consentirà di posizionare i componenti in modo tale da dividere la stessa dimensione 
orizzontale. Si tratta di un esempio molto semplice, ma ci permetterà comunque divedere quella che è 
la logica di gestione dei layout. 

Un primo aspetto da considerare riguarda le dimensioni delle view, che possono essere di due tipi; 

• measured; 

• effettive. 

Le prime sono quelle dimensioni che ogni componente vorrebbe avere quando è all'interno di un 
layout. Sono quelle che specifichiamo attraverso le costanti match_parent o wrap_content. Stiamo 
facendo riferimento alla parte evidenziata in questo frammento di layout: 

<Button 

android: ìd=" @ + id/buttonO " 

android: layout_width="match__parent " 

android : layout_height= " wrap_content " 

android : text="@string/button_label_0 " /> 

Attraverso questi valori stiamo richiedendo al layout contenitore di occupare tutto lo spazio 
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disponibile in larghezza (valore match_ P arent), mentre in altezza di accontentarci dello spazio 
necessario a contenere l'etichetta (valore wrap_content). Oltre a questi valori avremmo potuto 
specificare una dimensione costante attraverso un valore tipico di una dimensione, per esempio 50 
dp. Per accedere a queste informazioni si possono utilizzare i metodi 

public final int getMeasuredWidth ( ) 
public final int getMeasuredHeìght ( ) 

anch'essi final per lo stesso motivo dei metodi precedenti È importante sottolineare come il 
valore intero ritornato debba essere interpretato in modo particolare in quanto contiene sia le 
informazioni relative alla dimensione sia quelle relative agli eventuali vincoli Per ottenere questi dati è 
sufficiente utilizzare alcuni metodi statici della classe view.MeasureSpec nel seguente modo: 

int measuredwidth = getMeasuredWidth () ; 
int mode = MeasureSpec . getMode () ; 
int size = MeasureSpec . getSize () ; 

dove size esprime la dimensione richiesta e mode può assumere uno di questi valori 

MeasureSpec. AT_MOST; 
MeasureSpec . EXACTLY; 
MeasureSpec. UNSPECIFIED; 

Il valore at_most indica che la size specificata rappresenta un valore massimo. Couexactly si 
indica la richiesta di una dimensione precisa, mentre con unspecified si indica che non esiste alcun 
vincolo. 

La prima fase nell'elaborazione delle proprie view da parte diunviewGroup prende il nome di 
measuring e consiste nella consultazione delle dimensioni delle diverse measured. Questo avviene 
all'interno del metodo onMeasure < ) che nel nostro esempio è il seguente: 

SOverride 

protected void onMeasure (int widthMeasureSpec, int heightMeasureSpec) { 
int childCount = getChildCount ( ) ; 
ìf (childCount==0) { 

super . onMeasure (widthMeasureSpec, heightMeasureSpec) ; 
} else { 

int widthSize = MeasureSpec . getSize (widthMeasureSpec) ; 
mViewWidth = widthSize/chìldCount ; 

int measuredwidth = MeasureSpec .makeMeasureSpec (widthSize 

, MeasureSpec. EXACTLY) ; 
setMeasuredDimension (measuredwidth, heightMeasureSpec) ; 

} 

} 

I parametri passati contengono le informazioni relative allo spazio disponibile al nostro stesso 
layout, il quale è a sua volta inserito all'interno del layout associato all'activity. Attraverso il metodo 
getchìidcount ( ) verifichiamo quanti siano i componenti contenuti Nel caso in cui non ve ne fossero 
non facciamo nulla richiamando, attraverso il riferimento super, lo stesso metodo onMeasure o 
implementato nella classe viewGroup. In caso contrario otteniamo la dimensione relativa alla larghezza 
che dividiamo per il numero di componenti contenuti ottenendo quindi la larghezza da assegnare a 
ciascuno di essi. Un'operazione che deve essere richiamata in questo metodo è 
setMeasuredDimension o , che dovrà impostare la dimensione efièttiva del nostro layout. In questo 
caso non facciamo altro che ritornare le stesse specifiche per quello che riguarda l'altezza, mentre per 
la larghezza non abbiamo latto altro che assegnare il vincolo exactly a quanto ottenuto inizialmente. 
In questo metodo non abbiamo fatto altro che determinare la larghezza da assegnare a ogni 
componente. È un'informazione che abbiamo poi utilizzato nella seconda làse che si chiama "di 
layout" e che dovrà essere implementata cosi 

SOverride 
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protected void onLayout (boolean changed, int left, int top, int right, int bottom) { 
if (changed) { 

for (ìnt i=0; KgetChildCount ( ) ; i++) { 
View child = getChildAt (i) ; 
int viewLeft = i*mViewWidth; 

child. layout (viewLeft, top, viewLeft+mViewWidth, bottom); 

} 

} 

} 

Per ognuna delle view contenute non faremo altro che indicare la posizione e le dimensioni 
invocando su di esse il metodo layout ( ) che abbiamo evidenziato. È in questa fase che ogni 
componente acquisisce le proprie dimensioni effettive, ottenibili attraverso i seguenti metodi: 

public final ìnt getwidth() 
public final ìnt getHeightO 

Quello descritto è il procedimento di definizione di un layout personalizzato che comunque non è 
un'operazione molto frequente nello sviluppo delle applicazioni, anche perché esistono diversi layout 
che permettono di coprire la maggior parte dei casi È comunque un ottimo esercizio per 
comprendere a fondo la logica che viene utilizzata nella composizione delle diverse interfacce. 

Padding e margini 

Nel paragrafò precedente abbiamo creato un layout personalizzato molto semplice senza tener 
conto di due informazioni che prendono il nome di padding e margini. Sebbene il risultato che si 
ottiene possa sembrare simile, sono informazioni molto diverse tra loro. Il padding è una proprietà di 
ciascuna view e consente di specificare 'Timbottitura" che ogni componente può applicare al proprio 
contenuto. Per specificare le dimensioni del padding è possibile utilizzare questi attributi; 

android: paddingBottom 
android: paddingLef t 
android: paddingRight 
android : paddingTop 

Nel caso i valori nelle quattro posizioni coincidessero si può utilizzare anche l'attributo 

android: padding 

oppure il metodo 

public void setPadding (int left, int top, ìnt right, int bottom) 

I margini rappresentano invece un'informazione legata al contenitore e quindi al layout. Essi 
permettono di specificare lo spazio che un layout deve togliere alle view prima di poterle posizionare 
e ridimensionare al proprio interno. Qui gli attributi sono i seguenti: 

android: layout_marginBottom 
android: layout_marginLef t 
android: layout_marginRight 
android: layout_marginTop 

che notiamo, a conferma di quanto detto, contenere il prefisso layout_. 

I layout principali 

Come accennato, i layout messi a disposizione dalla piattaforma ci permettono ci coprire la 
stragrande maggioranza dei casi. A tale proposito vediamo i principali che sono il LinearLayout, il 

RelatìveLayout e il FrameLayout. 

Il LinearLayout 

II LinearLayout, descritto dall'omonima classe del package android. widget, permette di disporre 
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le view in esso contenute su una singola riga o colonna a seconda di quella che è la sua proprietà 
orientation. Si tratta del layout che abbiamo utilizzato quasi sempre nelle nostre interfacce, perché è 
il più semplice. Prima di realizzare un esempio descriviamo quelli che sono gli attributi che ci 
permettono di esaminare alcuni concetti che verranno ripresi anche in altri contesti. 

Per specificare se disporre i componenti su una riga o su una colonna si può utilizzare l'attributo 

android : layout_orientation 

il quale potrà assumere i valori horizontai e vertioai rispettivamente per una disposizione su una 
riga o colonna. La stessa informazione potrà essere specificata attraverso il metodo 

public void setOrientation (int orientation) 

con i due possibili valori rappresentati dalle costanti statiche horizontal e vertical della classe 

LinearLayout. 

La classe LinearLayout estende la classe ViewGroup che sappiamo definire una classe interna di 
nome viewGroup . LayoutParams per gli attributi che le view contenute dovranno specificare. Si tratta 
sicuramente di quelle relative alle dimensioni a cui la classe LinearLayout, attraverso la definizione 
della classe interna LinearLayout .LayoutParams, aggiunge quelle relative a gravità (gravity) e peso 

(weight). 

Per comprendere il funzionamento dei diversi layout non abbiamo la necessità di creare particolari 
progetti sfrutteremo invece l'editor di layout, che ci consente di avere una preview senza per forza 
installare l'applicazione nell'emulatore o in un dispositivo reale. 

NOTA 

Gli ultimi strumenti di preview all'interno di Android Studio ma anche del plug-in per eclipse stanno 
fortunatamente diventando sempre più affidabili. 

Per verificare il funzionamento di questo layout abbiamo creato il file linear_layout . xml'. 

<?xml version="l . 0" encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android. com/ apk/res/ android" 
android: layout_width="match__parent " 
android : layout_height= "match__parent " 
android: orientation="vertical" > 

<Button 

android: id="@+id/buttonl " 

android : layout_width="wrap_content " 

android: layout_height="wrap_content " 

android: text=" @string/button_label_l " > 
</Button> 

<Button 

android: id="@+id/button2 " 

android : layout_width="wrap_content " 

android: layout_height="wrap_content " 

android: text=" @string/button_label_2 " > 
</Button> 

</ LinearLayout > 

Innanzitutto vediamo la presenza degli attributi android : layout_width e android: layout_height 
applicati all'elemento <LinearLayout/>. Da quanto detto in precedenza questi attributi avrebbero 
senso solamente nel caso di view all'interno di Un ViewGroup. In realtà se proviamo a eliminarli 
noteremo come sul display non venga visualizzato alcun elemento, mentre nel caso di test di 
esecuzione si verificherebbe un errore. Attraverso i valori match__parent indichiamo quindi che la view 
occuperà tutto lo schermo a disposizione. In realtà la view che andiamo a specificare con il 
documento di layout viene aggiunta come figlia di un layout esistente associato aU'activity, per cui 
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necessita essa stessa delle informazioni sulle dimensioni. Il risultato è quello nella Figura 5.3. 




LayoutTest 
Button#l 

Button#2 



Figura 5.3 LinearLayout con orientamento verticale. 

Vediamo poi come l'orientamento sia quello verticale e come le view, rappresentate nell'esempio 
da semplici Button, vengano effettivamente messe una sopra l'altra. Modificando il valore in 
horizontal SI otterrebbe quanto mostrato nella Figura 5.4. 




Figura 5.4 LinearLayout con orientamento orizzontale. 

Il lettore potrà verificare cosa succede nel caso in cui vi fossero tante view da riempire lo schermo. 
In questo caso le view in eccesso non verrebbero visualizzate nella riga sottostante ma apparirebbero 
a destra sul display adattandosi a quello che è lo spazio disponibile. 
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Osservando gli attributi delle view contenute, e quindi dei Button, notiamo come il valore utilizzato 
per le dimensioni Sia wrap_content, che permette di occupare solamente lo spazio che serve alla 
visualizzazione delle etichette. Ciò che vogliamo lare ora è dividere equamente lo spazio disponibile 
tra i due pulsanti Un primo tentativo potrebbe essere quello di modificare la larghezza di entrambi i 
pulsanti assegnando il valore match_parent. Ciò che si ottiene è mostrato nella Figura 5.5, dove il 
primo pulsante occupa tutto lo spazio disponibile. 




Figura 5.5 Tentativo di dividere lo spazio disponibile in parti uguali. 



Questo comportamento, all'apparenza errato, è comunque legato al modo incuiAndroid 
attraversa l'albero delle view per poterle posizionare e ridimensionare. I due Button sono figli dello 
stesso LinearLayout, il quale non fa altro che elaborare le view contenute nell'ordine in cui sono 
descritte nel documento XML: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android . oom/ apk/res/ android" 
android: layout_width="match__parent " 
android: layout_height="match__parent " 
android: orientation="horizontal" > 

<Button 

android: id="@+id/buttonl " 

android : layout_width= "match__parent " 

android: layout_height="wrap_content " 
android: text=" @string/button_label_l " > 
</Button> 

<Button 

android: id="@+id/button2 " 

android : layout_width="match__parent " 

android: layout_height="wrap_content " 
android: text=" @string/button_label_2 " > 
</Button> 

</ LinearLayout > 

La prima view elaborata è quella del primo pulsante, il quale dice di voler occupare, in larghezza, 
tutto lo spazio disponibile, che in quel momento è quello dell'intera larghezza del display, per cui alla 
view viene data una larghezza effettiva pari a quella dell'intero display. Quando è il momento di 
valutare il secondo pulsante, tutto lo spazio a disposizione è nullo per cui la sua larghezza è nulla. 

Per ovviare a questo problema entra in gioco il concetto dipeso descritto dall'attributo 
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android: layout_weight 

che consente di indicare il peso che una view ha rispetto all'occupazione dello spazio disponibile in 
un particolare momento. Questo si esprime attraverso un valore numerico che indica in che 
proporzione ima view occuperà tutto lo spazio che ha a disposizione rispetto alle altre. Questo 
significa che uno stesso valore di peso per le due view consente di dividere lo spazio in parti uguali 
Un valore, per esempio, di 2 per la prima e 3 per la seconda, indica che dello spazio disponibile la 
prima ne occupa 3/5 e la seconda 2/5 (attenzione all'inversione dei valori). Nel nostro caso basterà 
dare uno stesso valore dipeso ai due pulsanti attraverso quanto descritto nel seguente documento: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android. oom/ apk/res/ android" 
android: layout_width="match__parent " 
android: layout_height="match__parent " 
android: orientation="horizontal" > 

<Button 

android: id=" @+id/buttonl " 

android : layout_width="match_jparent " 

android: layout_height="wrap_content " 

android : layout_weight= " 1 " 

android: text=" @string/button_label_l " > 
</Button> 

<Button 

android: id="@+id/button2 " 

android: layout_width="match_joarent " 

android: layout_height="wrap_content " 

android: layout_weight="l" 

android: text=" @string/button_label_2 " > 
</Button> 

</ Linear Layout > 

dove abbiamo evidenziato la parte relative al peso. Il corrispondente risultato è quello nella Figura 
5.30, dove i due pulsanti si dividono lo spazio a disposizione. 




LayoutTest 




Figura 5.6 Utilizzo dell'attributo layout_weight. 



Un'altra importante osservazione riguarda il dove le view contenute vengono inserite a partire dal 
vertice in alto a sinistra e poi nella direzione relativa all'orientamento. Attraverso l'attributo 
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android : layout_gravity 

è possibile specificare dove le diverse view vengono posizionate. Il nome è legato al latto che con 
questo attributo si può indicare dove "cadono" i vari componenti come se fossero sassi all'interno di 
una scatola. Aiutandoci con l'editor possiamo vedere come i valori per questo attributo siano quelli 
illustrati nella Figura 5.7 e di come possano essere combinati. 
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Figura 5.7 Alcuni valori dell'attributo di gravity. 



Specificando quando indicato nella figura per il primo pulsante, possiamo notare che lo stesso si 
posizionerà centralmente sia verticalmente sia orizzontalmente rispetto a quello che è lo spazio a 
disposizione (Figura 5.8). 
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Figura 5.8 Utilizzo di gravity. 



La parte di documento XML di riferimento sarà la seguente: 

<Button 

android: id=" @+id/buttonl " 

android: layout_width="match__parent " 

android: layout_height="wrap_content " 

android : layout_gravity= " center_vertical " 

android: layout_weight=" 1 " 

android : text="@string/button_label_l " > 
</Button> 

dove abbiamo evidenziato l'utilizzo dell'attributo android: layout_gravity. 

Relativamente a gravity il lettore potrà verificare l'esistenza di due attributi distinti: 

layout_gravity 

e 

gravity 

i quali possono assumere lo stesso insieme di valori; mentre il primo indica quella che è la direzione 
che un componente ha rispetto al proprio contenitore, il secondo descrive un valore relativo al 
proprio contenuto. Per comprendere la cosa è sufficiente modificare il valore dell'attributo gravity 
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(non iayout_gravity) del primo pulsante osservandone il risultato. Impostando, per esempio, il 
valore in questo frammento di codice: 



<Button 

android: id="@+id/button2" 

android: layout_width="match__parent " 

android: layout_height="wrap_content " 

android: layout_weight=" 1 " 

android : gravity= "top | right " 

android : text="@string/button_label_2 " > 

</Button> 



noteremo ima modifica nella posizione dell'etichetta del pulsante stesso come visualizzato nella 
Figura 5.9. 






LayoutTest 




Button#2 







Figura 5.9 Utilizzo dell'attributo gravity. 

Il lettore potrà verificare il funzionamento degli attributi relativi alla gestione del padding e dei 
margini in accordo a quanto detto e specificato nella documentazione ufficiale. Concludiamo la 
trattazione del LinearLayout ricordando che si tratta comunque di ima specializzazione della classe 
view, che quindi potrà essere contenuto all'interno di un altro layout che potrà essere a sua volta un 
LinearLayout . È quindi molto utile nel caso in cui si avesse la necessità di creare un'interfaccia i cui 
componenti possono essere organizzati in righe e colonne, anche se non ottimale dal punto divista 
delle prestazioni 



Il RelativeLayout 

Un altro interessante layout è quello descritto dalla classe RelativeLayout e consente di 
specificare la posizione di ogni view relativamente a quella del container o di altre esaminate in 
precedenza. Per comprenderne il funzionamento senza fornire un lungo elenco di attributi, consultabili 
nella documentazione ufficiale, facciamo un piccolo e semplicissimo esempio che prevede la creazione 
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di un forai per l'inserimento diusername e password (Figura 5.10). Creiamo il seguente file di layout 

relative_layout . xml: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<RelativeLayout xmlns : android="http : // schemas . android . corti/ apk/ res/ android" 
android : id=" @+id/ relativeLayout " 
android: layout_width="match_parent " 
android: layout_height="match__parent " > 

<EditText 

android: id=" @+id/username" 

android: layout_width="wrap_content " 

android: layout_height="wrap_content " 

andrò i d : layout_al ignP arentRight =" t rue " 

android : layout_toRightOf = " @+id/ usernameLabel " 

android : hint=" @string/username_hint " > 
</EditText> 

<TextView 

android: id=" @+id/usernameLabel " 

android: layout_width="wrap_content " 

android: layout_height="wrap_content " 

android : layout_alignBaseline= " @+id/username " 

android : layout_below= " @+id/password" 

android: text=" @st ring/ username_label " > 
</TextView> 

<EditText 

android: id="@+id/password" 

android: layout_width="wrap_content " 

android : layout_height="wrap_content " 

android: layout_alignLeft="@+id/username" 

android : layout_alignParentRight= " true " 

android : layout_below= " @+id/username " 

android: hint=" @string/password_hint " > 
</EditText> 

<TextView 

android: id=" @ + id/passwordLabel " 

android: layout_width="wrap_content " 

android: layout_height="wrap_content " 

android: layout_alignBaseline="@+id/password" 

android: text=" @string/password_label " > 
</TextView> 

</RelativeLayout> 

in cui abbiamo evidenziato gli attributi di interesse. A parte l'utilizzo dell'elemento 
<ReiativeLayout/>, è interessante notare come la posizione diogniview venga indicata rispetto a 
elementi già noti II primo componente è descritto da un'EditText, che vedremo essere uno dei 
componenti per l'inserimento di informazioni testuali Attraverso l'attributo 

android: iayout_aiignParentRight a true stiamo comunicando l'intenzione di allinearlo a destra con 
il proprio contenitore. Vediamo infatti come l'area di testo per l'inserimento dello username sia 
allineata a destra dello schermo. Attraverso l'attributo android: iayout_toRightof stiamo dicendo 
che questo componente dovrà stare alla destra di quello dell' id specificato dal corrispondente valore; 
nel nostro caso è un riferimento del tipo @id/usemameLabei, che è la Textview successiva la quale, 
attraverso l'attributo android :iayout_aiignBaseiine, dice di essere allineata rispetto alla parte 
testuale (baseline) con quella della precedente EditText. 
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Figura 5.10 Esempio di utilizzo del RelativeLayout. 



Abbiamo quindi la visualizzazione dell'etichetta Username a sinistra dell'EditText allineata 
verticalmente con il testo. 
NOTA 

A tal proposito dobbiamo fare una precisazione legata all'ordine di creazione dei componenti. 
Abbiamo già detto di come l'ordine di elaborazione segua quello di definizione nell'XML. 
L'implementazione di RelativeLayout fa tutto il possibile per ottenere il risultato voluto anche nel caso 
in cui, come il nostro, il primo componente faccia riferimento al secondo che non è ancora stato 
definito. La cosa importante, in questi casi, è comunque quella di evitare particolari strutture 
cicliche che mandino in confusione l'elaborazione del layout. In particolare è bene non legare alcune 
proprietà delle view a dimensioni totali che dipendono da quelle della view stessa. 

In relazione alla seconda area di testo, notiamo come questa venga posizionata sotto quella relativa 
allo username attraverso l'attributo android: layout_below, anch'essa allineata a destra con il 
container e con alla propria sinistra la corrispondente etichetta. Le indicazioni relative all'ultima 
Textview sono ora evidenti Si tratta di un layout molto utile nella realizzazione di forai in cui si 
richiede un certo allineamento tra i diversi componenti. 

Il FrameLayout 

Le precedenti implementazioni di viewGroup per la definizione di layout permettevano il 
posizionamento delle view definite all'interno del documento XML oppure create in modo 
programmatico attraverso le API Java. Il FrameLayout consente invece di avere controllo sulla 
visualizzazione delle view che contiene, fornendo gli strumenti per visualizzarne o nasconderne alcune. 
Per descrivere questo tipo di layout abbiamo creato questo documento XML: 
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<FrameLayout xmlns : android="http : / /schemas . android . com/apk/ res/android" 
android: id=" @+id/f rameLayout " 
android: layout_width="match__parent " 
android : layout_height="match__parent " > 

<LinearLayout 

android: id="@+id/greenFrame" 
android : layout_width="match_parent " 
android: layout_height="match_parent " 
android:background="#00FF00" > 

<Button 

android: id=" @+id/toBlueButton" 
android : layout_width="match__parent " 
android: layout_height="wrap_content " 
android: onClick="changeColor " 
android : text=" @string/to_blue_button" > 
</Button> 
</ Linear Layout > 

<Linear Layout 

android: id="@+id/blueFrame" 
android: layout_width="match_parent " 
android: layout_height="match_parent " 
android : background=" #000 OFF" 
android: visibility="gone" > 

<Button 

android: id=" @+id/toGreenButton" 
android : layout_width="match__parent " 
android : layout_height="wrap_content " 
android : onClick="changeColor " 
android : text=" @string/ to_green_button" > 
</Button> 
</ Linear Layout > 

</FrameLayout> 

Insieme all'utilizzo dell'elemento FrameLayout, rileviamo la presenza di due LinearLayout come 
figli ma avremmo potuto inserire un qualunque altro tipo di view. La cosa importante riguarda l'utilizzo 
dell'attributo android :visibiiity, usato per la seconda view, a cui abbiamo assegnato il valore 
gone. Questo sta a indicare che, delle view contenute nel FrameLayout, la seconda non sarà 
visualizzata. Attenzione: la visibility potrebbe assumere anche il valore invisibie, che si differenzia 
dal precedente per un aspetto fondamentale. Nel primo caso (valore gone) il risultato è quello che si 
otterrebbe nel caso in cui la view non esistesse ovvero non fosse mai stata inserita nel proprio 
contenitore. Nel secondo caso (valore invisibie) la view esiste ma non è visibile. Questo significa 
che, pur non vedendosi, occuperebbe comunque spazio. Si tratta quindi di un aspetto che è bene 
considerare. 

Il codice Java corrispondente aU'activity è molto semplice e consente di gestire gli eventi associati 
ai diversi pulsanti. Una cosa non ovvia è che non necessariamente deve essere visualizzata solo una 
delle view contenute. In realtà saranno visualizzate tutti quei componenti con visibilità corrispondente 
al valore visible. Nel caso specifico, il nostro esempio permette di commutare da una view all'altra, 
per cui il codice sarà del tipo: 

public void changeColor (View buttonSelected) { 
switch (buttonSelected . getld () ) { 
case R . id . toGreenButton : 

mGreenView. setvìsibility (View. VISIBLE) ; 
mBlueView. setvisibility (View. GONE) ; 
break; 

case R . id . toBlueButton : 

mGreenView. setvìsibility (View. GONE) ; 
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mBlueView. setvisibility (View . VISIBLE) ; 
break; 
default : 
break; 

} 

} 

Lasciamo al lettore la verifica del funzionamento dell'attività FrameActivity ricordandosi di 
dichiararla all'interno del file AndroidManif est . xml. 



Nuovi layout per UGHO 

Vogliamo ora implementare nella nostra applicazione i concetti visti iniziando dalla prima schermata 
che contiene i tre famosi pulsanti per la selezione delle opzioni di registrazione. Al momento la nostra 
interfaccia ha la preview mostrata nella Figura 5.11, che non è di certo un granché. Decidiamo quindi 
di centrare i pulsanti e di dare loro un aspetto più gradevole. 

Iniziamo con qualcosa di semplice aggiungendo un semplice sfondo alla schermata, cosa possibile 
attraverso la proprietà andr oid : background di ciascuna view e quindi anche del layout che abbiamo 
utilizzato (che ricordiamo essere un LinearLayout). Tale proprietà può assumere come valore il 
riferimento a una risorsa di tipo color oppure a un Drawable che ricordiamo essere l'astrazione di 
qualcosa che può essere visualizzato e che, nella maggior parte dei casi, viene appunto utilizzato come 
sfondo dei vari componenti. 
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Figura 5.11 Ul iniziale per il menu relativo alla modalità di login. 

Nel nostro caso vogliamo creare un particolare Drawable che ci permetta di impostare 
un' immagine di sfondo senza però avere immagini grandi per ognuna delle risoluzioni, dimensioni 
possibili. Definiamo poi una risorsa che si chiama BitmapDrawab le, che altro non è che un Drawable 
creato a partire da una particolare immagine che in Andro id viene descritta da istanze della classe 
Bitmap. Nella cartella che abbiamo definito come di default andiamo a creare il prossimo documento 
di nome bg.xmi: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<bitmap xmlns : android="http : // schemas . android . com/ apk/ res/ android" 
android: src="@drawable/paper_tile" 
android: tileMode=" repeat" /> 

A differenza di quanto visto finora, abbiamo definito un Drawable attraverso un documento XML 
e non attraverso un file relativo a un'immagine. In questo caso specifico stiamo creando un Drawable 
a partire dall'immagine associata alla risorsa drawabie/paper_tiie, che viene ripetuta per tutto lo 
spazio a disposizione. 

NOTA 

Immagini di questo tipo che permettono la creazione di sfondi attraverso la loro ripetizione si dicono 
tile (mattonelle). 
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A questo punto anche il precedente file bg . xml diventa ima risorsa Drawable come le altre, per cui 
le viene associata la costante r . drawable . bg e può quindi essere referenziata da un altro documento 
attraverso la notazione @drawabie/bg, come fatto nel prossimo documento di layout nel file 



f ragment_main . xml! 

<LinearLayout xmlns : android="http : / /schemas . android . com/ apk/res/ android" 
xmlns : tools="http : / / schemas . android. com/tools" 
android : layout_width="match__parent " 
android : layout_height="match_parent " 

android : paddingLef t="@dimen/ activity_horizontal_margin" 
android : paddingRight=" Sdimen/ activity_horizontal_margin" 
android : paddingTop=" @dimen/ activity_vertìcal_margin" 
android : paddingBottom=" @dimen/activity_vertical_margin" 
tools : oontext=" . FirstAccessActivity " 
android : orientation="vertical" 
android : background=" @drawable/bg" > 



// altro codice 
</ Linear Layout > 

Attraverso l'utilizzo dell'immagine nella Figura 5.12 abbiamo ottenuto il risultato nella Figura 5.13. 



Figura 5.12 Tile utilizzato per lo sfondo della nostra activity. 



198 





Figura 5.13 Risultato ottenuto con il BitmapDrawable creato. 

Beh sì, in effetti il colpo d'occhio non è eccezionale, e quella artistica non è la mia dote migliore. 
NOTA 

Vediamo come, mentre l'immagine del tile ha una versione diversa a seconda della risoluzione, il 
documento XML che ne descrive l'utilizzo come sfondo è definito solamente nella cartella associata 
ai Drawabledì default. Esso è infatti sempre lo stesso indipendentemente dalla risoluzione del 
display. 

Notiamo come ora si debbano sistemare i pulsanti iniziando a spostarli in una posizione centrata 
nello schermo e poi distanziandoli maggiormente. Per lare questo la prima opzione che ci verrebbe in 
mente sarebbe quella di dare a ogni pulsante un'altezza pari a match_parent utilizzando quindi 
l'attributo android:iayout_weight per dividere lo schermo in parti uguali 

<Button 

android: layout_width="match__parent " 
android : layout_height= "match__parent " 
android : layout_weight= " 1 " 

android: text="@string/anonymous_button_label" 
android: id=" @+id/anonymous_button" /> 

In questo modo il risultato sarebbe però quello nella Figura 5.14 che, se possibile, è persino 
peggiore del precedente. I pulsanti si sono infatti divisi tutto lo spazio a disposizione assumendo delle 
dimensioni sproporzionate. 
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Figura 5.14 Non il modo migliore per posizionare i nostri pulsanti. 

Come spesso succede la soluzione migliore è quella data dal RelativeLayout il quale, ricordiamo, 
ci permette di posizionare i pulsanti in una posizione relativa a quella del proprio contenitore o di altri 
componenti nello stesso. Dovremo quindi trasformare il LinearLayout ttl RelativeLayout e 
posizionare inizialmente il secondo pulsante centrato nel display ottenendo quanto mostrato nella 
Figura 5.15. 
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Figura 5.15 Un unico pulsante al centro del display in un RelativeLayout. 

Il codice del documento per ottenerlo, a cui abbiamo tolto per motivi di spazio gli attributi del 

RelativeLayout irrilevanti alla descrizione, è il seguente: 

<RelativeLayout ... android:background="@drawable/bg"> 
<Button 

android: layout_width=" f ill_parent " 
android: layout_height="wrap_oontent " 
android : layout_centerInParent= " true " 

android: text=" @st ring/ regi ster_button_label" 
android: id="@+id/ register_button"/> 

< /RelativeLayout > 

A parte il nuovo nome del container, vediamo come sia stato utilizzato l'attributo 
android : layout_center InParent, che consente appunto di centrare il particolare elemento nel 
layout. Ma perché abbiamo inserito prima il secondo pulsante e non il primo? Semplicemente perché 
ora inseriremo il primo e il terzo in posizioni relative al precedente e precisamente sopra e sotto lo 
stesso. Il layout che otteniamo è questo: 

<RelativeLayout ... android:background="@drawable/bg"> 
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<Button 

andrò id : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
andr oid : layout_centerInParent= " true " 
android : text=" @st ring/ regi ster_button_label" 
android : id="@+id/register_button" / > 

<Button 

android: layout_width=" f ill_parent " 
android: layout_height="wrap_oontent " 
android: text=" @string/ anonymous_button_label" 
android: layout_centerHorizontal=" true" 
android: layout_above="@+id/register_button" 
android: id="@+id/anonymous_button" /> 

<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_oontent " 
android: text=" @string/login_button_label" 
andr o i d : lay out_cent e rHor i z ont al = " t rue " 
android: layout_below="@+id/register_button" 
android: id="@+id/login_button" /> 

</RelativeLayout> 

con il risultato nella Figura 5.16. 

Qui è importante sottolineare l'esigenza di assegnare a ogni componente un id in modo che lo 
stesso possa essere utilizzato dagli altri componenti per làrne riferimento. Vediamo infatti come si tratti 
di informazioni utilizzate dagli attributi android : layout_above e android: layout_below. 

NOTA 

In realtà il riferimento ai componenti definiti precedentemente nello stesso layout, oppure in altri, 
dovrebbe prevedere l'utilizzo della forma android:ia Y out_beiow="@id/register_button", ovvero senza il +. 
Essa indica infatti che l'identificatore deve essere creato se non già esistente. Senza il + si assume 
che l'identificatore sia già stato creato. Nel nostro esempio il + è stato mantenuto in quanto, 
almeno in questa versione dell'IDE, la sua omissione provocherebbe un errore nella preview del 
layout. Probabilmente si tratta di un problema, comunque di poco conto, che verrà risolto in versioni 
successive. 

Per completare il layout in relazione al posizionamento dei pulsanti non ci resta che aggiungere dei 
margini che permettano di distanziarli. In questo caso abbiamo diverse opzioni, come quella di 
aggiungere dei margini solo al pulsante centrale oppure un margine superiore al terzo e un margine 
inferiore al primo. In questi casi è comunque buona norma applicare lo stesso attributo a tutti i pulsanti 
in modo da avere qualche possibilità in più di generalizzazione. Per questo motivo abbiamo aggiunto 
un margine inferiore a tutti i pulsanti nel seguente modo: 
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Figura 5.16 II layout con i pulsanti centrati nel display. 



<Button 

androidi: layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: text="@string/anonymous_button_label" 
android: layout_centerHorizontal="true" 
android: layout_above=" @id/register_button" 
android : layout_marginBottom= " 25dp " 
android: id=" @+id/ anonymous_button" / > 

Il bravo lettore potrebbe comunque obiettare, a ragione, sull'utilizzo di un valore letterale (qui 
25dp) per la distanza. Per questo motivo non tacciamo altro che definire una risorsa di tipo dimen: 

<dimen name="button_margin_bottom">2 5dp</dimen> 

e poi utilizzarla nella precedente definizione nel seguente modo: 

<Button 

android : layout_width=" f ill_parent " 

android: layout_height="wrap_content " 

android : text=" @string/ anonymous_button_label" 

android: layout_centerHorizontal="true" 

android: layout_above=" @id/register_button" 

android : layout_marginBottom= " @dimen/button_margin_bottom" 
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android: id=" @+id/anonymous_button" /> 

A questo punto abbiamo ottenuto il layout nella Figura 5.17. Ancora non abbiamo fatto un granché, 
per cui decidiamo di "abbellire" i pulsanti. In questi casi la prima scelta del profano è quella di creare 
un' immagine da impostare come background del pulsante, oltre a scegliere un colore e una 
dimensione per il testo. Prendiamo allora fimmagine nella Figura 5.18, che inseriamo nel nostro 

progetto COn il nome no_patch.png. 




Figura 5.17 Abbiamo centrato e distanziato i pulsanti. 




Figura 5.18 Immagine utilizzata come sfondo dei pulsanti. 

Come detto, la prima soluzione prevede di impostare questa immagine come background di ogni 
pulsante, la cui definizione diventerebbe quindi la seguente: 

<Button 

android: layout_width=" f ill_parent " 
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android: layout_height="wrap_content " 
android: text=" @string/ anonymous_button_label" 
android: layout_centerHorizontal="true" 
android: layout_above=" @+id/register_button" 
android : background= " @drawable/no_patch " 

android: layout_marginBottom="@dimen/button_margin_bottom" 
android: id=" @+id/anonymous_button" /> 

il quale produrrebbe quanto riportato nella Figura 5.19. Qui ci sono principalmente due grossi 
problemi 




Figura 5.19 II risultato dell'uso dell'immagine precedente come sfondo dei pulsanti. 

Il primo dipende da una deformazione dell'immagine di sfondo dovuta al fatto che essa si adatta 
alle dimensioni dell'oggetto a cui è stata applicata. Nel nostro caso i pulsanti occupavano tutto lo 
spazio in larghezza ma spesso si hanno problemi perché uno stesso pulsante contiene etichette di 
lunghezza diversa a seconda della lingua. 

Per esempio, il tedesco contiene vocaboli in media molto più lunghi dei corrispondenti inglesi. Il 
secondo problema, a cui daremo una soluzione più avanti, si può osservare solamente eseguendo 
l'applicazione: il lettore noterà come i pulsanti quando vengono premuti non modifichino in alcun 
modo il proprio aspetto, mantenendo sempre lo stesso colore grigio. Questo perché i pulsanti 
necessitano di un tipo particolare di Drawable che è appunto sensibile allo stato delle view a cui 
vengono applicati. Vediamo un problema per volta. 

Utilizzo dei Nine Patch Drawable 

Nel paragrafo precedente abbiamo visto il problema principale che si ha quando si cerca di 
utilizzare un'immagine come background per un componente di dimensioni variabili; spesso capita che 
si deformi in modo non idoneo. Per risolvere questo problema, la piattaforma Android ci mette a 
disposizione un particolare tipo di immagini PNG che prendono il nome di NinePatch. Se torniamo ai 
nostri oggetti di tipo Button, possiamo notare come la parte che dovrebbe modificare le proprie 
dimensioni è solamente quella centrale che contiene il testo. 

Le immagini di tipo NinePatch ci permetteranno di specificare questa zona e istruire in qualche 
modo l'ambiente affinché venga eseguito un ridimensionamento opportuno. Il nome stesso NinePatch 
deriva dalla possibilità di suddividere l'immagine in nove parti, come nella Figura 5.20, dove le 
quattro parti esterne vengono modificate solamente in altezza e quella inferiore e superiore in 
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larghezza. La parte centrale, che dovrà presurnibilmente contenere gli elementi di dimensione variabile 
(per esempio un testo), dovranno essere ridimensionate in entrambe le direzioni 
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Figura 5.20 Suddivisione in nove parti secondo lo schema NinePatch. 



Come detto, l'SDK Android fornisce un tool specifico che ci permette di convertire un' immagine 
PNG normale in un'immagine NinePatch. A tale proposito apriamo un prompt dei comandi e 
digitiamo 

draw9patch 

È un tool il cui eseguibile è contenuto nella cartella <android_home>/tools e che vogliamo 
utilizzare per sistemare la precedente immagine no_patch.png. Per fare questo è sufficiente eseguire 
l'applicazione e trascinarvi dentro il file da modificare ottenendo quanto mostrato nella Figura 5.21. 
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Figura 5.21 II tool dopo averci trascinato dentro l'immagine no_patch.png. 



Vediamo come l'immagine caricata venga visualizzata nella parte sinistra, mentre nella parte destra 
vi sia la visualizzazione della stessa per le tre situazioni in cui il contenuto è più alto, più largo o lasciato 
inalterato. La parte sulla destra rappresenta una preview del risultato che si vuole ottenere. Nella 
parte sinistra abbiamo volutamente selezionato l'immagine con il mouse per mettere in risalto un 
bordo di 1 pixel che sarà il nostro punto di intervento. Con il clic del mouse potremo selezionare 
alcuni di questi pixel colorandoli di nero. Tenendo premuto il tasto Maiusc sarà possibile 
deselezionare i pixeL II significato di questi pixel varia a seconda che vengano selezionati nella parte 
sinistra e in alto o nella parte bassa e a destra. La parte sinistra e in alto consente di selezionare quelle 
regioni dell'immagine che potranno essere ridimensionate. Le parti non selezionate in alto o a sinistra 
definiscono le zone che non subiranno ridimensionamento. Per quello che riguarda la parte a destra e 
in basso, il significato della selezione dei pixel è quello di definizione dell'area che un elemento potrà 
occupare se contenuto nell'immagine stessa. Si tratta spesso di una regione un po' più ampia di quella 
definita. Possiamo allora procedere ottenendo, nel nostro caso, una situazione del tipo nella Figura 
5.22. 
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Figura 5.22 II risultato delle selezioni. 

Per maggiore chiarezza abbiamo tracciato delle linee. Quelle più interne delineano le nove zone 
relative all'immagine NinePatch come descritto all'inizio del paragrafo. Le linee più esterne 
definiscono invece l'area che andrà a contenere l'eventuale elemento centrale, come per esempio un 
testo. Un volta completata questa gestione andremo a salvare il file con un'estensione che ora sarà 
. 9.png. Nel nostro caso abbiamo trasformato l'immagine no_patch.png nell'immagine di nome 
patched. 9 .png, che andiamo subito a sostituire alla precedente nel nostro layout. 

NOTA 

Il lettore non si aspetti protocolli o sistemi di compressione particolari nella gestione di queste 
immagini. Sono semplicemente delle immagini con un pixel completamente nero sul contorno che 
viene quindi interpretato in modo corretto dai componenti che lo utilizzano. 

Come la precedente, è un'immagine che verrà messa nella risorse insieme alle altre e per la quale 
verrà creata in modo automatico una costante della classe R. drawable. Tornando al nostro progetto, 
ogni pulsante sarà così definito: 

<Button 

android: layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android : text=" @string/ anonymous_button_label" 
android: layout_centerHorizontal="true" 
android: layout_above=" @+id/register_button" 
android : padding= " @dimen/button_menu_padding" 
an droi d:back groun d= "@dra wabl e /patched" 

android: layout_marginBottom="@dimen/button_margin_bottom" 
android: id=" @+id/anonymous_button" /> 

dove abbiamo aggiunto un padding al fine di non avere dei pulsanti troppo sottili II risultato sarà 
quello nella Figura 5.23. 
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Figura 5.23 Utilizzo delle risorse NinePatch. 



Come possiamo notare, sebbene l'immagine utilizzata non sia di grande qualità, lo sfondo non è più 
deformato ma mantiene un arrotondamento che tiene conto delle dimensioni dei pulsanti Come il 
lettore potrà intuire, questo tipo di immagini presenta un altro vantaggio, e cioè che le parti di 
dimensioni variabili possono di fatto essere, nell'immagine originale, di 1 pixel Questo permette la 
creazione di immagini più piccole che occupano quindi meno spazio. 

I Drawable dipendenti dallo stato 

Nella parte iniziale di questo capitolo abbiamo descritto quelle che sono le caratteristiche principali 
di ogni view, tra cui quella di delegare a un particolare Drawable la propria renderizzazione. Il 
pulsante ci dimostra però che i diversi componenti non hanno un unico stato e che questo può variare 
il modo in cui gli stessi vengono visualizzati II pulsante, per esempio, dovrebbe essere disegnato in 
modo diverso quando premuto oppure quando disabilitato. Quello che abbiamo realizzato in 
precedenza invece, anche se intercetta perfettamente gli eventi resta sempre lo stesso traendo in 
inganno l'utente. Lo stato di una view è rappresentato da un insieme di valori interi a cui possiamo 
accedere attraverso il metodo: 

public int [ ] getStateO 

o modificato attraverso il seguente metodo: 

public boolean setState (int[] stateSet) 

Ogni componente dichiara nella propria implementazione la capacità di essere "sensibile" a un 
particolare stato definendo la corrispondente costante e reagendo alla stessa delegando a Drawable 
diversi la propria renderizzazione. Nella maggior parte dei casi non abbiamo la necessità di utilizzare 
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questi metodi o di definire stati personalizzati, ma possiamo semplicemente utilizzare un tipo di risorsa 
che si chiama stateListDrawabie, che può essere creata attraverso un opportuno documento XML 
da inserire nella cartella delle risorse Drawable come già fatto per lo sfondo. Quello che vorremmo 
ottenere è la visualizzazione del pulsante che modifica il proprio aspetto quando premuto. Non 
avendo a disposizione un' immagine del pulsante come la precedente ma una più scura, decidiamo 
inizialmente di utilizzare dei semplici colori. Ricorrere ai colori dove ci si aspetta dei Drawable non è 
esattamente la stessa cosa, per cui inizialmente creiamo quelli che si chiamano coiorDrawabie e che 
non sono altro che dei Drawable ottenuti a partire da una determinata risorsa di tipo color. Per farlo 
creiamo queste definizioni all'interno del nostro file colors . xml nella cartella res/values: 

<color name="grey">#BBBBBB</color> 
<color name="light_grey">#EEEEEE</color> 
<color name="dark_grey ">#555555</color> 

<color name="button_pressed_color">@color/ dark_grey</ color> 
<color name="button_not_pressed_color">@oolor/ grey</ color> 
<color name="button_f ocused_color">@ color /light_grey< / color > 

«drawable name="button_pressed_drawable">@color/button_pressed_color</drawable> 
<drawable name="button_not_pressed_drawable">@color/button_not_pressed_color</drawable> 
<drawable name="button_f ocused_drawable">@color/button_f ocused_color</drawable> 

dove notiamo come siano stati utilizzati gli elementi <drawabie/> per trasformare delle risorse di 
tipo color in risorse di tipo Drawable. Arriviamo finalmente alla creazione della risorsa di tipo 
stateListDrawabie attraverso il seguente documento XML nel file button_bg.xmi: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<selector xmlns : android="http : //schemas . android . com/ apk/res/android"> 
<item android: state_pressed="true" 

android : drawable= " @drawable/button__pressed_drawable "/ > 

<! — pressed — > 

<item android: state_focused="true" 

android : drawable= " @drawable/button_f ocused_drawable " / > 

<! — focused — > 

<item android: drawable="@drawable/button_not_pressed_drawable" /> 

<! — default — > 
</selector> 

Vediamo come si tratti di una risorsa definita attraverso l'elemento <seiector/> al cui interno si 
definiscono tanti elementi <item/> quante sono le possibili configurazioni di stato che si intendono 
gestire. Per una determinata view, ciascuno stato può essere attivato oppure no, si può, per ognuna 
combinazione distati, impostare un Drawable attraverso F omonimo attributo. Notiamo poi come 
esistano tanti attributi quanti sono gli stati che il componente può assumere. Per testarne il 
funzionamento questa volta è necessario eseguire l'applicazione e premere uno dei pulsanti come fatto 
da noi nella Figura 5.24. Vediamo allora che il secondo pulsante, nello stato pressed, assume lo 
sfondo grigio scuro come voluto. 
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Figura 5.24 II secondo pulsante è nello stato pressed (premuto). 

A questo punto restano due problemi di cui uno ormai ricorrente. Il primo riguarda il colore della 
scritta che nel caso in cui il pulsante fosse nello stato pressed diventa difficilmente leggibile. Il secondo 
è invece che i pulsanti sono tutt'altro che gradevoli Per risolvere il primo problema la piattaforma ci 
mette a disposizione una risorsa di tipo color anch'essa sensibile allo stato della view a cui viene 
applicata. Si tratta di loiorstateList e, sebbene non sia un Drawable, viene definita in modo simile 
attraverso il seguente documento: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<selector xmlns : android="http : / / schema s . android . com/ apk/ res/android"> 
<item android: state_pressed="true" 

android : color= " @color/white "/> 

<! — pressed — > 

<item android: state_f ocused="true" 

android: color="@color/black"/> 
<! — focused — > 

<item android: color="@ co lor/black"/> 
<! — default — > 
</ selector> 

Sono risorse che si definiscono sempre attraverso gli elementi <seiector/> e <item/> ma questa 
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volta l'attributo è androidi : color, che consente appunto di fare riferimento a un colore; mentre nel 
caso precedente, la risorsa veniva impostata come background, ora dovremo impostarla come colore 
del testo: 

<Button 

android: layout_width=" f ill_parent " 

android: layout_height="wrap_content " 

android: text="@string/anonymous_button_label" 

android: layout_centerHorizontal="true" 

android: layout_above=" @+id/register_button" 

android : padding= " @dimen/button_menu_padding" 

android :background="@drawable/button_bg" 

android: textColor="@color/button_text_color" 

android: layout_marginBottom="@dimen/button_margin_bottom" 

android: id=" @+id/ anonymous_button" / > 

Eseguendo l'applicazione e riproducendo la situazione precedente il risultato sarà come quello nella 
Figura 5.25. 
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Figura 5.25 Utilizzo di una ColorStateList per modificare il colore del testo. 

Abbiamo visto come sia possibile utilizzare delle risorse dipendenti dallo stato di una view per 
modificare, di conseguenza, sia lo sfondo sia i colori 
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Risorsa di tipo Shape 

Nel paragrafo precedente abbiamo risolto il problema della renderizzazione del pulsante che ora 
cambia di colore quando premuto. Per tarlo abbiamo perso quanto guadagnato dalla creazione della 
risorsa NinePatch. Vogliamo allora rimediare creando i pulsanti con bordo arrotondato attraverso 
l'utilizzo di una nuova risorsa di tipo Drawable definita attraverso un documento XML. Abbiamo 
definito la seguente risorsa che abbiamo descritto nel file button_shape_normai . xml e che abbiamo 
inserito nella cartella res/drawable di default: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<shape xmlns : android="http : / /schemas . android. com/ apk/res/android" 
androidi shape="rectangle"> 

<corners android : radius=" @dimen/button_corners_width" / > 

<solid android : color=" @color/button_not_pressed_color " / > 

<stroke 

android: color=" dcolor/black" 

android : width=" @dimen/button_stroke_width" / > 

</ shape> 

Innanzitutto le risorse di questo tipo vengono create attraverso l'uso dell'elemento <shape/>, che 
dispone di diversi attributi tra cui quello evidenziato, che ci permette di decidere se è un rettangolo, 
una linea un ovale o un anello. Nel nostro caso abbiamo esplicitato la forma rettangolare, anche se 
sarebbe comunque stata quella di default. Attraverso l'elemento <comers/> possiamo specificare il 
raggio di arrotondamento degli angoli Nel nostro caso abbiamo impostato tale dimensione attraverso 
una risorsa di tipo dimen. Inizialmente abbiamo deciso di utilizzare gli stessi colori definiti, cosa che 
abbiamo dichiarato attraverso l'elemento <soiid/>, il colore di riempimento della figura che si sta 
descrivendo. 

Abbiamo poi deciso di definire, attraverso l'elemento <stroke/>, un bordo di cui abbiamo 
specificato il colore e lo spessore. Analogamente a quanto fatto per questa risorsa ne abbiamo 
definite di analoghe per gli altri stati del nostro pulsante che abbiamo poi utilizzato per definire il nuovo 
sfondo, sensibile allo stato, nel file di nome button_bg_shape.xmi, che riportiamo di seguito e che 
ormai non dovrebbe più riservare sorprese per il nostro lettore: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<selector xmlns : android="http : //schemas . android . com/ apk/ re s /android" > 
<item android: state_pressed="true" 

android: drawable="@drawable/button_shape_pressed"/> 
<item android: state_f ocused="true" 

android: drawable=" @drawable/button_shape_f ocused" /> 
<item android : drawable=" @ drawable /button_shape_normal" /> 
</ selector> 

Il risultato è quello nella Figura 5.26, che assomiglia molto a quanto ottenuto con l'immagine 
NinePatch ma ora sensibile allo stato e ottenuto senza l'aggiunta di immagini ma semplicemente in 
maniera dichiarativa attraverso un documento XML. 
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Figura 5.26 Utilizzo delle risorse di tipo Shape unite a uno StateListDrawable. 

Sinceramente il colore uniforme (solid) non rende moltissimo, per cui decidiamo di applicare un 
minimo gradiente attraverso l'apposito elemento. Per fare questo abbiamo semplicemente definito 
nuovi colori per la versione leggermente più scura e leggermente più chiara e quindi dichiarato la 
seguente risorsa di tipo Shape all'interno dei file button_gradient_normai.xmi: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<shape xmlns : andrò id=" http : / / schema s . andrò id . com/apk/ res/android" 
android: shape="rectangle"> 
<corners android : radius=" @dimen/button_corners_width" / > 
<gradient 

android: startColor="#333333" 
android: endColor="#333333" 

android: centerColor="@color/button_not_pressed_color" 
android : angle= " 90 " /> 

<stroke 

android : colo r= " Scolo r/black" 

android : width=" @dimen/button_stroke_width" / > 

</shape> 

Vediamo come gli attributi principali dell'elemento <gradient/> permettano di specificare il colore 
di partenza, quello centrale e quello finale del gradiente che verrà definito in modo automatico in fase 
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di renderizzazione. Se non specificato diversamente, il gradiente andrà da sinistra a destra. Nel nostro 
caso vorremmo creare un gradiente verticale per cui abbiamo utilizzato F attributo androidi: angle 
impostandolo al valore di 90 gradi. 
NOTA 

Questo attributo non può assumere valori qualsiasi ma solamente dei multipli di 45 che sono intesi 
in gradi. 

Applicando lo stesso meccanismo anche agli altri Drawable e definendo il corrispondente 
documento XML per la risorsa stateListDrawabie, il risultato sarà quello nella Figura 5.27. 
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Figura 5.27 Utilizzo di risorse di tipo Shape con gradiente. 

Anche qui i colori scelti lasciano a desiderare ma lasciamo al lettore, come utile esercizio, la 
responsabilità di una scelta cromatica più felice. 



Assets e font 

A parte gli aspetti puramente cromatici, non ci sentiamo soddisfatti di quanto creato in quanto 
vorremmo impostare anche il font per le varie etichette. Se andiamo a osservare la struttura delle 
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directory del nostro progetto, notiamo la presenza di una cartella di nome lassets, che non è 
contenuta all'interno della cartella res delle risorse in quanto ha un significato particolare. Come 
sappiamo, per ciascuna risorsa all'interno di res viene generata in modo automatico ima costante della 
classe r. In realtà il sistema, in tàse di building dell'applicazione, esegue su queste risorse una sorta di 
ottimizzazione. Per esempio, per quelle basate su documento XML, vengono realizzate alcune 
operazioni che ne consentiranno poi ilparsing in fase di esecuzione. La cartella assets si può invece 
considerare come un piccolo file system accessibile in lettura dall'applicazione. Per i file all'interno di 
questa cartella (non parliamo infatti di risorse sebbene vengano spesso considerati tali) non vengono 
fatte ottimizzazioni di alcun tipo e neppure generate costanti per poter avere dei riferimenti 
successivamente. In questa cartella metteremo quindi tutto ciò che dovrà rimanere com'era nel 
momento in cui è stato creato. Una tipologia di file che si inseriscono in questa cartella sono quelli 
relativi ai font. L'unico modo per accedere a queste informazioni è l'utilizzo della classe 

AssetManager. 
NOTA 

Non essendoci un identificatore creato in modo automatico dall'ambiente, questo tipo di risorse non 
potrà essere referenziato dall'interno di un documento XML come avviene in genere attraverso la 
ormai classica sintassi @tì P o/nome_risorsa. 

Per questo tipo di risorse vogliamo creare la cartella associata agli assets e poi una cartella di 
nome font che conterrà il file con estensione TTF (True Type Font) che utilizzeremo per le etichette 
del nostro pulsante. Il lettore attento avrà subito notato come la cartella assets non sia presente nella 
gerarchia delle cartelle del nostro progetto. 

NOTA 

Coloro che stanno utilizzando eclipse e hanno creato il loro progetto attraverso l'ADT, noteranno 
come la cartella assets venga creata in corrispondenza della creazione del progetto. Al momento 
con Android Studio è diverso, e tale cartella va aggiunta in modo esplicito. 

Per aggiungere la cartella /assets nel nostro progetto in Android Studio dobbiamo selezionare il file 
con estensione .imi associato al modulo del progetto e verificare la presenza dell'impostazione che 
abbiamo evidenziato nel seguente file, che nel nostro caso si chiama ugho-ugho . imi: 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<module external . system . ìd=" GRADLE " type=" JAVA_MODULE" version="4"> 
<component name= " FacetManager "> 

<facet type="android" name="Android"> 
<conf iguration> 

<option name= " SELECTED_BUILD_VARIANT " value="debug" /> 
<option name="ASSEMBLE_TASK_NAME " value="assembleDebug" /> 
<option name= " ALLOW_USER_CONF I GURAT I ON " value=" false " /> 
<opt i on name= " GEN_FOLDER_RELAT I VE_P ATH_APT " 
value="/UGHO/build/source/aidl /debug" /> 

<option n ame = " MAN I F E S T_F I LE_RE LATI VE_P AT H " value=" /src/main/AndroidManif est . xml" 

/> 

<option name= " RE S_FOLDER_RELAT I VE_P ATH " value=" / src/main/res " /> 
<option name="ASSETS_FOLDER_RELATIVE_PATH" value="/src/main/assets" /> 

</ conf iguration> 
</f acet> 



</component> 
</module> 

Qualora non fosse stata presente avremmo dovuto aggiungerla in modo esplicito facendo puntare 
la cartella che nel nostro caso è all'interno dclmain dei nostri sorgenti Creiamo poi la cartella font 
nella quale inseriamo il file font_exampie .ttf, come possiamo vedere nella Figura 5.28. 
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▼ Clsrc 
▼ E] main 
▼ Q assets 
▼ E] font 

jf font_example.ttf 

► Djava 

► ti res 

<> And roid Manifestami 
@ .gitignore 
©build.gradle 
build.gradle 
0 gradlew 

Figura 5.28 Struttura delle cartelle per gli assets. 

In Andro id ogni font viene rappresentato da un oggetto di tipo Typef ace che, una volta ottenuto 
dagli assets, può essere applicato a tutte le view che prevedano la gestione di un contenuto testuale. 
Nel nostro caso la lettura dell'oggetto Typef ace implica l'uso di queste poche istruzioni: 

AssetManager assetManager = getResources ( ) . getAssets ( ) ; 

Typef ace typef ace = Typef ace . createFromAsset (assetManager ," fonts/f ont_example . ttf" ) ; 
che nel nostro FirstAccessFragment diventano le seguenti: 

private static final String BUTTON_FONT_PATH = " font /font_example . ttf " ; 

// Carichiamo il font 

final AssetManager assets = getActivity (). getAssets () ; 

final Typef ace buttonFont = Typef ace . createFromAsset (assets, BUTTON_FONT_PATH) ; 

final Button anonymousButton = (Button) f irstAccessView 

. f indViewByld (R. id. anonymous_button) ; 
anonymousButton . set Typef ace (buttonFont) ; 

anonymousButton . setOnClickListener (new View . OnClickListener ( ) { 
SOverride 

public void onClick (View view) { 
if (mListener != nuli) { 

Log. d (TAG_LOG, "User requests to enter as anonymous ! " ) ; 
mListener . enterAsAnonymous () ; 

} 

} 

}) ; 

che, applicate anche agli altri pulsanti (e cambiato il colore del testo) della UI, portano al risultato 
della Figura 5.29, che non si può vedere nella preview del nostro tool ma richiede l'esecuzione 
dell'applicazione. 



217 



Abbiamo poi approfittato della volontà di inserire dei font personalizzati per descrivere quelle che 
sono delle tipologie di "risorse" fondamentali come gli assets. 
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Figura 5.29 Utilizzo di font personalizzati all'interno della nostra applicazione. 



Temi e stili 

Dopo aver cambiato la UI della schermata di primo accesso ci si presenta la necessità di applicare 
le stesse modifiche alle altre parti dell'applicazione. Osservando la definizione di uno dei pulsanti la 
cosa ci può spaventare, in quanto ci mette di fronte a una serie lunghissima di copia e incolla: 

<Button 

androidi : layout_width=" f ill_parent " 

android: layout_height="wrap_content " 

android: text=" @string/ anonymous_button_label" 

android: layout_centerHorizontal="true" 

android : layout_above=" @+id/register_button" 

android :padding= " @dimen/button_menu_padding" 

android: background= " @drawable/button_bg_gradient " 

android: text Colo r=" @ color /button_text_col or " 

android: layout_marginBottom="@dimen/button_margin_bottom" 

android: id=" @+id/anonymous_button" /> 
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Fortunatamente, Android ci consente di definire e utilizzare un ulteriore tipo di risorsa che prende il 
nome di tema o stile e che ha uno scopo simile a quello dei CSS {Cascading Style Sheet) per le 
pagine HTML. Come vedremo si tratta di risorse che vengono definite in modo molto simile: mentre 
uno stile può essere applicato ai componenti, i temi possono essere assegnati a un'activity oppure a 
un'intera applicazione e sono sostanzialmente un insieme di stili. Vediamo allora come poter ottenere 
degli stili e dei temi da quanto definito nel nostro layout; iniziamo dagli oggetti di tipo Button, che 
andiamo a selezionare nella finestra di nome Component Tree premendo il tasto destro del mouse e 
selezionando l'opzione Refactor > Extract Style (Figura 5.30) oppure direttamente nella versione 
visuale del layout come nella Figura 5.31. 
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Figura 5.30 Opzione Extract Style in Component Tree. 
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Refactor ► Extract Style... 



Go To Declaration §€B Inline Style... 

Extract Layout... 

Inline Layout... 

\\ f xà:(S 

Figura 5.31 Opzione Extract Style nella finestra di layout. 

Questa opzione ci permette di estrarre dal componente quelle proprietà che potrebbero essere 
definite in uno stile e descritte nella risorsa relativa. Quello che si ottiene è infatti la schermata nella 
Figura 5.32, nella quale abbiamo inserito il nome main_button_styie come identificatore. Notiamo 
come inizialmente siano selezionati tutti gli attributi, compresi quelli relativi al layout, che noi abbiamo 
però deselezionato. Si tratta infatti di valori che non caratterizzano il componente ma la sua posizione 
all'interno di un layout. E quindi buona norma non inserire nella definizione degli stili questo tipo di 
informazione al fine di una maggiore riutilizzabilità. 
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© O O Extract Android Style 



Style name: main_button_style 



0 Launch 'Use Style Where Possible' refactoring after the style is extracted 
Attributes: 



□ layout_width [fill_parent] 

Q layout_height [wrap_content] 

□ layout_centerHorizontal [true] 

Q layout_above [@+id/register_button] 

padding [@dimen/button_menu_padding] 
$ background [@drawable/button_bg_gradient] 
(V^ textColor [@color/button_text_color] 
Q layout_marginBottom [@dimen/button_margin_bottom] 



0 



Cancel ) [ OK 



Figura 5.32 Selezione degli attributi che fanno parte del nuovo stile. 

Per verificare cosa succede non ci resta che premere il pulsante OK. All'apparenza sembrerebbe 
non essere successo nulla ma se andiamo a vedere il file di nome styies . xml noteremo la creazione 
della seguente risorsa del nome da noi dato: 

<style name="main_button_style"> 

<item name=" android: padding" >@dimen/button_menu_padding</item> 
<item name= "android: background" >@drawable/butt on_bg_gradient</ item> 
<item name=" android: textColor ">@ color /button_text_color</item> 
</style> 

Si tratta appunto della risorsa di tipo style che abbiamo estratto dal componente precedentemente 
selezionato. E al nostro pulsante che cosa è successo? Se andiamo a vedere il documento di layout 
ora il nostro componente è così definito: 

<Button 

android : layout_width=" f ill_parent " 

android: layout_height="wrap_content " 

android: text="@string/anonymous_button_label" 

android: layout_centerHorizontal="true" 

android : layout_above=" @+id/register_button" 

android: layout_marginBottom="@dimen/button_margin_bottom" 

android: id=" @+id/anonymous_button" 

style= " @ style/main_button_style " / > 

dove vediamo l'utilizzo dell'attributo style (senza ilnamespace android) valorizzato con il 
riferimento alla precedente risorsa di stile. Abbiamo da un lato semplificato il layout e dall'altro creato 
uno stile che potrà essere applicato a tutti i pulsanti semplicemente utilizzando l'attributo style. Il 
nostro layout, relativamente alla definizione degli oggetti Button, diventa il seguente: 

<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: layout_center!nParent="true" 
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android : text = " Sstring/ regìster_button_label " 

android: layout_marginBottom="@dimen/button_margin_bottom" 

style= " @ style/main_button_style " 

android : id=" @+id/ register_button" /> 

<Button 

android : layout_width=" f ill_parent " 

android : layout_height="wrap_content " 

android : text=" @string/anonymous_button_label" 

android : layout_centerHorizontal="true" 

android: layout_above="@+id/ register_button" 

android: layout_marginBottom="@dimen/button_margin_bottom" 

android: id=" @+id/ anonymous_button" 

style= " @ style/main_button_style" / > 

<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android : text=" @string/ login_button_label" 
android : layout_centerHorizontal="true" 

android : layout_marginBottom= " @dimen/button_margin_bottom" 
android: layout_below="@+id/register_button" 
style= " @ style/main_button_style " 

android: id=" @+id/login_button" /> 

Nel nostro caso il layout è un ReiativeLayout, che gode della proprietà di essere il più efficiente in 
quanto le fasi di measuring e di layout prevedono una sola scansione degli elementi in esso contenuti. 
Per contro è un layout alquanto verboso: per ogni componente è spesso necessario specificare un 
elevato numero di attributi di layout. Quando si utilizzano altri tipi di layout, gli stili portano a una 
notevole semplificazione dei documenti XML. Un altro vantaggio è quello di rappresentare un unico 
punto in cui intervenire nel caso di modifiche. Ora, la modifica dello sfondo corrisponde alla semplice 
modifica del relativo attributo nella risorsa di tipo styie e non richiede alcuna ricerca né operazioni di 
copia/incolla. 

A questo punto il passo successivo consisterebbe nella ricerca di tutti i pulsanti della nostra 
applicazione per potervi applicare lo stile appena definito. In realtà Android ci consente di fare 
qualcosa di più attraverso la definizione di un tema che potremo poi applicare alle diverse attività 
oppure all'intera applicazione. Nel nostro caso, possiamo definire la seguente risorsa che descrive 
appunto un tema: 

<style name="UghoTheme" parent="AppTheme"> 

<item name="android:buttonStyle">@style/main_button_style</item> 
<item name=" android: windowBackground">@drawable/bg</item> 
</style> 

Una prima importantissima osservazione riguarda il fatto che ogni tema è la specializzazione di un 
tema esistente attraverso Fattributo parent. Attenzione: nel nostro caso il tema da estendere si chiama 
AppTheme, che è diverso a seconda della versione della piattaforma che andrà a eseguire 
l'applicazione. Se andiamo a osservare i relativi file di configurazione notiamo come il tema AppTheme 
di default abbia questa definizione: 

<style name= "AppTheme" parent="AppBaseTheme"> 
</style> 

<style name="AppBaseTheme" parent= " android : Theme . Light"> 

</style> 

ovvero estenda il tema AppBaseTheme che a sua volta estende il tema Theme. Light definito nella 
piattaforma. Dalla versione corrispondente all' API Level 1 1 la definizione è la seguente: 

<style name= "AppTheme" parent= "AppBaseTheme "> 
</style> 

<style name= "AppBaseTheme" parent= "android: Theme .Holo . Light "> 

</style> 
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chi ci permette di accedere alle funzionalità del tema Theme . Holo . Light. Infine, per i dispositivi con 
API Level uguale o superiore a 14 abbiamo questa definizione: 

<style name="AppTheme" parent="AppBaseTheme"> 
</style> 

<style name="AppBaseTheme" parent=" android: Theme . Holo . Light . DarkActionBar" > 

</style> 

NOTA 

In realtà il tema A PP Theme aggiunge un livello al momento superfluo, che comunque ci può consentire 
un'eventuale ulteriore specializzazione dei temi per le altre attività. 

Tornando al nostro tema, abbiamo poi utilizzato la seguente definizione che è di fondamentale 
importanza in quanto ci permette di dire che, se utilizziamo questo tema, tutti i pulsanti dovranno 
utilizzare il tema specificato dallo stile @styie/main_button_styie. Questa definizione è quella che ci 
eviterà di applicare lo stile a tutti i pulsanti della nostra attività: 

<item name="android:buttonStyle">@style/main_button_style</ item> 

Nella nostra activity avevamo modificato anche il background, cosa possibile ora attraverso questa 
definizione: 

<item name=" androidi : windowBackground">@drawable/bg</item> 

Attenzione: non si tratta dall'attributi background ma di quello di nome windowBackground. Gli 
attributi e le combinazioni possibili sono infatti moltissime e possono essere consultate nella 
documentazione ufficiale oppure, ancora meglio, fatte suggerire dall'IDE in fase di editing. 

Il passo successivo è quello di applicare il tema alla nostra attività oppure all'intera applicazione. 
Nel nostro caso abbiamo la necessità di gestire attività con sfondi e strutture diverse (per esempio la 
splash), per cui decidiamo di applicare il tema alle attività interessate in modo esplicito una a una. Il 
nostro layout diventa quindi il seguente, nel quale rileviamo la completa assenza delle informazioni 
relative agli stili precedenti; 

<RelativeLayout xmlns : android="http : //scheraas . android . com/ apk/res/ android" 
xmlns : tools="http : / /schemas . android . com/ tools " 
android: layout_width="match_jparent " 
android: layout_height="match_parent " 

android : paddingLef t="@dimen/activity_horizontal_margin" 
android: paddingRight=" @dimen/activity_horizontal_margin" 
android: paddingTop="@dimen/ activity_vertical_margin" 
android : paddingBottom=" @dimen/activity_vertical_margin" 
tools : context=" . FirstAccessActivity " > 

<Button 

android: layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: layout_centerInParent="true" 
android : text=" @st ring/ regi ster_button_label" 
android : layout_marginBottom="@dimen/button_margin_bottom" 
android: id="@+id/register_button" / > 
<Button 

android: layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: text=" @string/ anonymous_button_label" 
android: layout_centerHorizontal="true" 
android : layout_above=" @+id/ register_button" 
android: layout_marginBottom="@dimen/button_margin_bottom" 
android : id=" @+id/ anonymous_button" / > 
<Button 

android : layout_width=" f ill_parent " 
android: layout_height="wrap_content " 
android: text=" @string/login_button_label" 
android: layout_centerHorizontal="true" 

android: layout_marginBottom="@dimen/button_margin_bottom" 
android: layout_below=" @+id/register_button" 
android: id="@+id/ login_button" /> 
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</RelativeLayout> 

L'applicazione del tema all'attività avviene nel file di configurazione AndroidManif est . xml, dove 
abbiamo utilizzato questa definizione: 

<activity 

android: name=" . activity . FirstAccessActivity " 
android: theme="@style/UghoTheme "/> 

Eseguendo l'applicazione il lettore potrà notare come il risultato sia lo stesso del caso precedente a 
differenza del fatto che ora le etichette dei pulsanti sono tutte allineate a sinistra. Questo perché 
probabilmente il tema che abbiamo esteso aveva questa impostazione per l'attributo gravity, che 
andiamo a sistemare nel nostro stile nel seguente modo: 

<style name="main_button_style"> 

<item name=" android : padding">@dimen/button_menu_padding</item> 
<item name=" android: background" >@drawabl e /button_bg_gradient</ item> 
<item name=" android: t ext Color ">@ color /button_text_color</item> 
<item name= "android: gravity ">center</item> 

</style> 

ottenendo il risultato nella Figura 5.33 come ci aspettavamo. 

Il vantaggio dell'utilizzo di un tema consiste nel poterlo applicare alle diverse attività che 
erediteranno l'aspetto visuale che abbiamo appena definito. In questa fase dobbiamo notare tre 
aspetti importanti. Il primo è che attraverso il tema non abbiamo impostato alcun layout per cui 
dovremo eseguire il passaggio dalLinearLayout alReiativeLayout anche per le altre schermate con 
l'elenco deiButton. La seconda considerazione riguarda il fatto che alcune schermate dispongono 
anche di componenti EditText che dovremo andare a gestire creando uno stile opportuno da 
includere all'interno del tema per tutti i componenti di quel tipo. La terza è relativa all'utilizzo del font 
personalizzato, cosa che dovrà essere necessariamente gestita a livello di codice in quanto, finora, non 
si può impostare il font in modo dichiarativo direttamente dall'interno del documento XML di layout. 
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Figura 5.33 Utilizzo di un tema per ottenere lo stesso risultato. 

Per quello che riguarda l'EditText, abbiamo quindi definito il seguente stile: 

<style name="main_edìttext_style" parent="@android: style/Widget .EditText"> 

<item name=" android : padding">@dimen/button_menu_padding</item> 
<item name=" androidi background" >@drawable/edittext_gradient_bg</item> 
<item name="android: textColor">@oolor/black</ item> 
<item name="android: textSize">@dimen/ edittext_text_size</item> 
</style> 

che notiamo avere questa volta una particolarità, ovvero estendere uno stile esistente. In realtà 
questo è quello che accade di solito; uno stile descrive solamente quelli che sono i valori diversi degli 
attributi rispetto a quelli già definiti da parte di imo stile o tema esistente. Per fare in modo che ogni 
EditText utilizzi questo stile all'interno del nostro tema, basterà aggiungere questa definizione: 

<style name="UghoTheme" parent="AppTheme"> 

<item name="android: buttonStyle">@style/main_button_style</item> 
<item name= " android : editTextStyle " >@ style/main_edittext_style</item> 

<item name=" android: windowBackground">@drawable/bg</ item> 
</style> 

per poi applicare il tema anche alle schermate che prevedono un inserimento di informazioni come 
quella relativa al login (Figura 5.34). 
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Abbiamo approfittato della nostra applicazione per verificare P effettiva utilità della definizione degli 
stili e quindi dei temi Una ultimissima osservazione riguarda Fuso di una particolare sintassi che 
potrebbe risultare poco chiara ma che noi non abbiamo comunque impiegato nel nostro progetto. 



>f Collegato come dispositivo multimediale 



Logi 



Username: 



Password: 



J 
] 





Figura 5.34 Utilizzo dello stile per gli EditText. 

A volte si ha infatti la necessità di assegnare a un attributo di uno stile il valore di un altro attributo 
dello stile che si sta specializzando e di quello impostato come parent. Si utilizza allora questa sintassi; 

<style name="MyTextViewStyle" parent=" @android : style/Widget . Ho lo . Light . TextView"> 
<item name="android: textColor ">?android: textColorSecondary</item> 

</style> 

In questo esempio, il significato è quello di assegnare all'attributo textcoior il valore dell'attributo 

textColorSecondary in qualche modo ereditato. 



Creazione di un componente personalizzato 

Come promesso concludiamo questo capitolo conia creazione di un componente personalizzato 
per la scelta della data di nascita. Android offre un componente che si chiama DatePicker che non 
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sempre piace agli utenti Per questo motivo realizzeremo un nostro caiendarchooser. Si tratta di un 
componente che creeremo a scopo didattico che quindi non comprenderà una serie di ottimizzazioni 
che renderebbero il codice difficilmente leggibile. Prima di cominciare diciamo che il risultato che 
vogliamo ottenere è quello nella Figura 5.35 ovvero un calendario all'interno di una finestra di dialogo 
descritta da un' opportuna specializzazione della classe DialogFragment. 

Dal punto divista grafico, tanto per cambiare, non è un granché, ma è un esercizio che ci 
consentirà di vedere diversi concetti importanti nello sviluppo di componenti personalizzati in Android. 
La strada infatti è piuttosto lunga, per cui è bene mettersi da subito in cammino. 



O A ?.dl 14:1 




<r ~z> CZ^l cfzf 1 



Figura 5.35 II nostro CalendarChooser in esecuzione. 

Diciamo subito che realizzeremo questo componente utilizzando due approcci diversi. Il primo ci 
permetterà di creare il componente attraverso la definizione di un particolare layout e una serie di 
Textview ciascuna corrispondente al nome dei giorno della settimana e ai giorni del mese. Il secondo 
approccio utilizzerà invece gli strumenti di più basso livello come quelli che ci permetteranno di 
scrivere sul Canvas del componente. 

NOTA 

Chi ha avuto esperienza di programmazione con MIDP si ricorderà della possibilità di utilizzare la 
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grafica di alto livello e quella di basso livello. La prima permetteva la creazione di interfacce grafiche 
attraverso la composizione di elementi come liste, caselle di controllo, pulsanti e simili, mentre la 
seconda consentiva di disegnare direttamente sul display. La prima modalità è la più semplice in 
quanto permette di aggregare componenti esistenti anche se non consente un'elevata 
personalizzazione degli stessi. La seconda offre un elevato grado di personalizzazione grafica al 
prezzo di dover però gestire diverse cose, tra cui gli eventi. Nel nostro caso potremo associare le 
API di alto livello all'utilizzo di Textview e layout e le API di basso livello al disegno vero e proprio 
dell'interfaccia attraverso gli strumenti offerti dalla piattaforma. 

Il primo passo del componente di alto livello che abbiamo chiamato caiendarchooser consiste 
nella definizione di un documento di layout che abbiamo definito nel file di nome 

widget_calendar_chooser .xml e che riportiamo di Seguito: 

<?xml version="l . 0" encoding="ut f-8 " ?> 

<RelativeLayout xmlns : android="http : // schemas . android . com/ apk/res/ android" 
android : orientat ion=" vertical " 
android: id=" @+ìd/ calendar_widget " 
android: layout_width=" @dimen/calendar_width" 
android: layout_height=" @dimen/calendar_height " 
style="@style/CalendarStyle"> 

<RelativeLayout 

android: id=" @+id/calendar_header " 
android: layout_width="match_parent " 
android: layout_height="wrap_content " 
android: layout_alignParentTop="true" 
android : orientat ion="hori zont al "> 

<ImageButton 

android : id=" @+id/calendar_previous_button" 

android: layout_wìdth="wrap_content " 

android: layout_height="wrap_content " 

android : src=" @drawable/ oalendar_previous_item" 

android : layout_alìgnParentLef t="true " 

android : layout_alignParentTop="true"x/ImageButton> 

<ImageButton 

android: id=" @+id/calendar_next_button" 

android: layout_wìdth="wrap_content " 

android : layout_heìght="wrap_content " 

android : src=" @drawable/ calendar_next_item" 

android : layout_alìgnParentRight="true" 

android : layout_alignParentTop="true"x/ImageButton> 

<TextView 

android : id=" @+id/ calendar_month_label" 
android: layout_width="wrap_content " 
android: layout_height="wrap_content " 
android: text="@string/placeholder_month_name " 
android: layout_alignParentTop="true" 
android: gravity="center" 

android : textSize=" gdimen/ calendar_month_text_size" 
android: layout_toRightOf =" @+id/ calendar_previous_button" 
android: layout_alignBottom=" @+id/calendar_previous_button" 
android : layout_toLef tOf =" @+id/ calendar_next_button"x/TextView> 
</RelativeLayout> 
<LinearLayout 

android: id="@+id/calendar_name_days_container" 
android : layout_width= "match__parent " 
android : layout_height= " wrap_content " 
android: orientation="horizontal" 
android : layout_below= " @+id/calendar_header " > 
</LinearLayout> 
<LinearLayout 

android : orientation= "vertical " 

android: id="@+id/calendar_days_container" 

android : layout_width= "match__parent " 
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android : layout_height= " wrap_content " 

android: layout_below="@+id/calendar_name_days_container"> 
</Linear Layout > 

</RelativeLayout> 

Come possiamo notare abbiamo diviso il layout in due parti. Quella superiore, che utilizzeremo 
anche nella versione successiva del componente, contiene semplicemente due imageButton per la 
navigazione avanti e indietro tra i mesi e una Textview per il nome del mese corrente. Su questa parte 
non perdiamo altro tempo, in quanto si tratta di un normale layout di cui poi gestiremo i valori in base 
alla data correntemente visualizzata nel nostro calendario. Le parti interessanti sono invece quelle 
evidenziate che utilizzeremo per "iniettare" delle Textview in modo dinamico. Nel primo contenitore 
aggiungeremo le Textview relative ai nomi dei giorni della settimana, mentre nella seconda inseriremo i 
giorni veri e propri. Per essere precisi, nella prima andiamo effettivamente a inserire delle Textview, 
mentre nella seconda andremo a inserire delle specializzazioni che descriveremo attraverso la classe 

interna DayTextView. 

NOTA 

Le icone relative al nostro componente possono essere scaricate dalla documentazione ufficiale 

al I ' i ndi riZZO http : / /developer . android . com/design/ downloads /index. html. 

Rispetto alla Textview questo nostro componente dispone di imo stato legato al giorno che la 
stessa rappresenta, che potrebbe essere il giorno corrente, quello selezionato, quello del mese 
corrente o un qualunque altro giorno. A seconda di quello che l'oggetto rappresenta vogliamo infatti 
dare una visualizzazione diversa. Una volta definito il layout andiamo a descrivere la classe 
caiendarchooser che rappresenta il nostro componente personalizzato di alto livello: 

public class CalendarChooser extends FrameLayout { 
public interface OnCalendarChooserListener { 
/** 

* Questo viene invocato quando c'è una selezione nel dateChooser 

* @param source The CalendarChooser source of this selectìon 

* Spararli selectedDate The selectedDate 
*/ 

voìd dateSelected (CalendarChooser source, Date selectedDate); 

} 

private OnCalendarChooserListener mOnCalendarChooserListener; 

public void setOnCalendarChooserListener (final OnCalendarChooserListener 
OnCalendarChooserListener) { 

this .mOnCalendarChooserListener = OnCalendarChooserListener; 

} 



Innanzitutto notiamo come la nostra classe estenda la classe FrameLayout. In realtà nel nostro caso 
la classe padre non è molto importante in quanto andremo successivamente a eseguire Y inflette del 
layout creato in precedenza. 

NOTA 

Ricordiamo che Untiate è l'operazione che consente di ottenere una particolare specializzazione di 
view a partire dal documento XML che la descrive. 

Nel frammento di codice riportato vediamo come sia stato implementato un meccanismo di listener 
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per la gestione della selezione. Il nostro componente notificherà infatti la selezione ogni volta che 
questa verrà fatta da parte dell'utente. Facciamo attenzione che non siamo ancora all'interno della 
finestra di dialogo per la quale la selezione della data dovrà avere un comportamento diverso. 

La seconda parte della nostra classe fa riferimento invece alla parte di inizializzazione, prima 
attraverso i costruttori e poi attraverso la definizione di un metodo privato di utilità di nome init ( ) : 

public CalendarChooser (Context context) { 
super (context) ; 

mCurrentDate = Calendar . getlnstance (Locale . getDefault ()) ; 
init () ; 

} 

public CalendarChooser (Context context, AttributeSet attrs) { 
super (context, attrs); 

mCurrentDate = Calendar . getlnstance (Locale . getDefault ()) ; 
init () ; 

} 

private void initO { 

RelativeLayout calendarView = (RelativeLayout ) Layoutlnf later . f rom (getContext ( ) ) 

. inf late (R. layout . widget_calendar_chooser , nuli) ; 
mMonthTextVìew = (TextView) calendarView. findViewByld (R. id. calendar_month_label) ; 
calendarView. f indViewByld (R. id. calendar_previous_button) 

. setOnClickListener (new OnClickListener ( ) { 

SOverride 

public void onClick (View view) { 

mCurrentDate . add (Calendar . MONTH, -1) ; 
updateUIO; } 

}) ; 

calendarView . f indViewByld (R . id . calendar_next_button) 

. setOnClickListener (new OnClickListener ( ) { 

@Override 

public void onClick (View view) { 

mCurrentDate .add (Calendar . MONTH, 1) ; 
updateUI ( ) ; 

} 

}) ; 

mDaysContainer = (LinearLayout) calendarView 

. f indViewByld (R . id . calendar_days_container ) ; 
mDayNamesContainer = (LinearLayout) calendarView 

. f indViewByld (R. id. calendar_name_days_container ) ; 
addView (calendarView) ; 
updateUI () ; 

} 

I costruttori delle specializzazioni delle view dispongono solitamente di tre overload del costruttore. 
Il primo, con un solo parametro di tipo context, viene utilizzato nel caso in cui si abbia la necessità di 
istanziare il componente da codice come avremo noi in questa implementazione. Qui non vengono 
infatti passate le informazioni di layout che dovranno essere impostate in modo imperativo. Il secondo 
costruttore permette invece il passaggio di queste informazioni di layout, ed è quello che viene 
solitamente invocato quando definiamo il componente all'interno di un layout. Noi non lo faremo ma 
consigliamo al lettore di verificare il funzionamento dei nostri componenti all'interno di un layout 
attraverso una definizione di questo tipo: 

<uk . co . massimocarli . android. ugno . widget . CalendarChooser 
android: id=" @+id/birth_date_calendar_chooser " 
android: layout_width="wrap_content " 
android : layout_height="wrap_content " /> 

che nel caso dell'implementazione di alto livello sarà invece del tipo: 

<uk . co . massimocarli . android . ugho . widget . GraphCalendarChooser 
android : id=" @+id/birth_date_graph_calendar_chooser " 
android : layout_width="wrap_content " 
android : layout_height="wrap_content " /> 



230 



Nei costruttori impostiamo quindi la data di default, quella corrente, e richiamiamo il metodo 
init ( ) di inizializzazione che esegue alcuni semplici operazioni Innanzitutto esegue Yinflate del layout 
precedenti e ottiene i riferimenti ai diversi componenti grafici; primi fra tutti i contenitori che dovremo 
poi riempire in base allo stato del nostro calendario. Notiamo poi come si ottengano i riferimenti ai 
componenti di tipo imageButton e si gestiscano i relativi eventi attraverso delle implementazioni di 
onciickListener che aggiungono e tolgono 1 mese dalla data corrente. Per un approfondimento sulla 
classe caiendar rimandiamo alla documentazione ufficiale di Java. Nel nostro caso eseguiamo 
semplicemente istruzioni del tipo: 

mCurrentDate . add (Caiendar. MONTH, -1) ; 
mCurrentDate . add (Caiendar. MONTH, 1) ; 

Infine, nelle due istruzioni evidenziate non facciamo altro che aggiungere la view ottenuta alla 
gerarchia che ha come root il nostro componente e richiamare il metodo updateui ( ) , che di fatto 
contiene tutta la logica di aggiornamento dello stato del nostro calendari 

private void updateUIO { 

mDayNamesContainer . removeAUViews ( ) ; 
mDaysContainer . removeAUViews ( ) ; 

final String currentMonth = MONTH_DATE_FORMAT . format (mCurrentDate . getTime ()) ; 
mMonthTextView . setText (currentMonth . toUpperCase ( ) ) ; 

int maxWeekNumber = mCurrentDate . getActualMaximum (Caiendar . WEEK_OF_MONTH ) ; 
final LinearLayout . LayoutParams dayNamesLp = new LinearLayout 
. LayoutParams (LinearLayout . LayoutParams . MATCH_PARENT 
, LinearLayout . LayoutParams . WRAP_CONTENT) ; 

dayNamesLp . weight = 1; 

final int f irstDaylnTheWeek = mCurrentDate . getFirstDayOf Week () ; 
final Caiendar utilCalendar = Caiendar . getlnstance () ; 
for (int i = 0; i < DAYS_IN_A_WEEK; i++) { 

final int currentDay = ( f irstDaylnTheWeek + ì) % DAYS_IN_A_WEEK; 

utilCalendar . set (Caiendar . DAY_OF_WEEK, currentDay) ; 

final String shortDayName = 
DAY_IN_WEEK_FORMAT . format (utilCalendar . getTime ( ) ) ; 

final TextView dayTextView = new TextView (getContext () ) ; 

dayTextView . setGravity (Gravity . CENTER) ; 

dayTextView. setPadding (DAY_PADDING, DAY_PADDING, DAY_PADD ING , DAY_PADDING) ; 
dayTextView. setLayoutParams (dayNamesLp) ; 
dayTextView. setText (shortDayName) ; 
mDayNamesContainer . addView (dayTextView) ; 

} 

final Caiendar f irstOf TheMonth = Caiendar . getlnstance () ; 
f irstOf TheMonth . setTime (mCurrentDate . getTime ( ) ) ; 
firstOf TheMonth. set (Caiendar . DAY_OF_MONTH, 1) ; 
int firstDay = f irstOf TheMonth . get (Caiendar . DAY_OF_WEEK) ; 
final int dayOffset = firstDay - f irstDaylnTheWeek; 
final LinearLayout . LayoutParams dayRowLp = new LinearLayout 
. LayoutParams (LinearLayout . LayoutParams . MATCH_PARENT 
, LinearLayout . LayoutParams . WRAP_CONTENT) ; 
utilCalendar . setTime (f irstOf TheMonth . getTime ( ) ) ; 
utilCalendar. add (Caiendar . DATE, -1 * dayOffset); 
final Caiendar now = Caiendar . getlnstance () ; 
final int today = now . get (Caiendar . DAY_OF_YEAR) ; 
final int todayYear = now . get (Caiendar . YEAR) ; 

final int selectedDay = mCurrentDate . get (Caiendar . DAY_OF_YEAR) ; 
final int selectedMonth = mCurrentDate . get (Caiendar . MONTH) ; 
final int selectedYear = mCurrentDate . get (Caiendar . YEAR) ; 
for (int week = 0; week < maxWeekNumber; week++) { 

final LinearLayout dayRow = new LinearLayout (getContext ()) ; 

dayRow . setLayoutParams (dayRowLp) ; 

mDaysContainer . addView (dayRow) ; 

for (int i = 0; i < DAYS_IN_A_WEEK; i++) { 

final Caiendar itemDate = Caiendar . getlnstance () ; 
itemDate . setTime (utilCalendar . getTime ( ) ) ; 

final DayTextView dayTextView = new DayTextView (getContext () , itemDate); 
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dayTextView . setGravity (Gravity . CENTER) ; 

dayTextView.setPadding(DAY_PADDING, DAY_PADD ING , DAY_PADDING, 

DAY_PADDING) ; 

dayTextView. setLayoutParams (dayNamesLp) ; 

int dayToShow = utilCalendar . get (Calendar . DATE) ; 
dayTextView . setText ( " " + dayToShow) ; 

final int currentDaylnYear = utilCalendar . get (Calendar . DAY_OF_YEAR) ; 
final int ourrentMonthYear = utilCalendar . get (Calendar . MONTH) ; 
final int currentYear = utilCalendar . get (Calendar . YEAR) ; 
if (selectedDay == currentDaylnYear && selectedYear == currentYear) { 

dayTextView. setSelectedDay (true) ; 
} else if (today == currentDaylnYear && todayYear == currentYear) { 

dayTextView. setToday (true) ; 
} else if (currentMonthYear == selectedMonth) { 

dayTextView. setThisMonth (true) ; 
} else { 

dayTextView. setOtherMonth (true) ; 

} 

dayTextView. setClickable (true) ; 

dayTextView. setOnClickListener (mOnClickListener) ; 
dayRow . addView (dayTextView) ; 

utilCalendar. add (Calendar. DATE, 1) ; 

} 

} 

} 

Nel codice precedente abbiamo evidenziato tutto quello che riguarda la creazione della gerarchia 
delle view tralasciando i dettagli relativi al calcolo delle informazioni da visualizzare, che il lettore potrà 
approfondire direttamente leggendo i commenti presenti nel codice ed eliminati qui per motivi di 
spazio. Una prima osservazione riguarda la modalità con cui sono state iniettate le informazioni 
relative al layout, attraverso la definizione di oggetti di questo tipo: 

final LinearLayout . LayoutParams dayRowLp = new LinearLayout 

.Layout? arams (LinearLayout . LayoutParams .MATCH_PARENT 
, LinearLayout .LayoutParams . WRAP_CONTENT) ; 

In questa fase è bene fare attenzione al fatto che i tipi di oggetto LayoutParams non sono legati a 
quelli dell'oggetto in cui vengono utilizzati ma al tipo del layout che li contiene. 
NOTA 

Se abbiamo un LinearLayout contenuto all'interno di un FrameLayout, l'oggetto che vi applicheremo sarà 

del tipo FrameLayout. LayoutParams e non del tipO LinearLayout .LayoutParams. 

Il secondo aspetto, di maggiore importanza, riguarda l'utilizzo del componente descritto dalla 
classe DayTextView che è ima specializzazione di Textvìew ma che gestisce un insieme personalizzato 
di stati. Abbiamo infatti deciso di utilizzare quanto imparato in relazione alla gestione di Drawable 
sensibili allo stato per fare in modo che questo componente assuma un aspetto diverso a seconda che 
rappresenti il giorno corrente, quello selezionato e così via. Il primo passo in questo senso consiste 
nella definizione di questi stati personalizzati attraverso la seguente risorsa che abbiamo descritto nel 

file calendar_chooser . xml in /res/values! 

<declare-styleable name="calendar_day "> 

<attr name=" state_other_month" f ormat="boolean" /> 

<attr name="state_this_month" format="boolean"/> 

<attr name="state_today" f ormat="boolean" /> 

<attr name=" state_day_selected" f ormat="boolean" /> 
</declare-styleable> 

Vediamo come si tratti di valori molto simili a quelli utilizzati nel caso di Button ma con nomi 
diversi. Insieme a questo tipo di attributi ci servirà quindi una risorsa Drawable in grado di ascoltarli e 
una view a essi sensibile. La prima è stata implementata nel file cai endar_day_bg . xml nella cartella 
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delle risorse Drawable di default: 



<?xml version="l . 0" encoding="utf-8 " ?> 

<selector xmlns : android="http : //schemas . android . com/ apk/res/android" 
xmlns : app="http: //schemas . android. com/ apk/res/uk . co .massimocarli . android. ugho"> 
<item 

app : state_this_month="true" 
app : state_today=" false" 
app : state_other_month=" false" 
app : state_day_selected=" false" 

android: drawable=" @drawable/ calendar_this_month_bg_color " /> 

<item 

app : state_this_month=" false" 
app : state_today="true" 
app : state_other_month=" false" 
app : state_day_selected=" false" 

android: drawable=" @ drawable/ calendar_today_bg_color " /> 
<item 

app : state_this_month=" false" 
app : state_today=" false" 
app : state_other_month="true" 
app : state_day_selected=" false" 

android: drawable="@ drawable/ calendar_other_month_bg_color " /> 
<item 

app : state_this_month=" false" 
app : state_today=" false" 
app : state_other_month=" false" 
app : state_day_selected="true" 

android: drawable="@ drawable/ calendar_selected_bg_color " / > 
</ selector> 

In questa fase è di fondamentale importanza notare come i nostri attributi personalizzati debbano 
essere associati a un namespace associato a sua volta al package della nostra applicazione, ovvero a 
quello a cui appartengono le costanti della classe R.attrs generate in modo automatico. 

Serve poi una classe che preveda tra i propri stati quelli definiti e che deleghi, in base a essi, al 
Drawable corretto la propria renderizzazione; questo componente è descritto dalla nostra classe 

DayTextViewI 

public static class DayTextView extends TextView { 



private static final int[] STATE_TODAY = {R. attr . state_today} ; 

private static final int[] STATE_DAY_SELECTED = {R.attr. state_day_selected} ; 

private static final int[] STATE_THIS_MONTH = { R . attr . state_this_month } ; 

private static final int[] STATE_OTHER_MONTH = { R . attr . state_other_month } ; 



private boolean mToday = false; 
private boolean mThisMonth = false; 
private boolean mOtherMonth = false; 
private boolean mSelectedDay = false; 
private Calendar mltemDate; 



public DayTextView (final Context context, final Calendar itemDate) { 
super (context) ; 
this .mltemDate = itemDate; 

setBackgroundResource (R. drawable . calendar_day_bg) ; 



public void setToday (final boolean today) { 
this. mToday = today; 
if (today) { 
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mThisMonth = false; 
mOtherMonth = false; 
mSelectedDay = false; 

} 

} 

public void setThisMonth ( final boolean thisMonth) { 
this .mThisMonth = thisMonth; 
ìf (thisMonth) { 

mToday = false; 
mOtherMonth = false; 
mSelectedDay = false; 

} 

} 

public void setOtherMonth ( final boolean otherMonth) { 
this .mOtherMonth = otherMonth; 
ìf (otherMonth) { 
mToday = false; 
mThisMonth = false; 
mSelectedDay = false; 

} 

} 

public void setSelectedDay ( final boolean selectedDay) { 
this .mSelectedDay = selectedDay; 
ìf (selectedDay) { 
mToday = false; 
mThisMonth = false; 
mOtherMonth = false; 

} 

} 

@Override 

protected int[] onCreateDrawableState (int extraSpace) { 

final int[] drawableState = super. onCreateDrawableState (extraSpace + 4); 
if (mToday) { 

mergeDrawableStates (drawableState, STATE_TODAY) ; 

} 

if (mSelectedDay) { 

mergeDrawableStates (drawableState, STATE_DAY_SELECTED) ; 

} 

if (mThisMonth) { 

mergeDrawableStates (drawableState, STATE_THIS_MONTH) ; 

} 

if (mOtherMonth) { 

mergeDrawableStates (drawableState, STATE_OTHER_MONTH) ; 

} 

return drawableState; 

} 

public Calendar getltemDate ( ) { 
return mltemDate; 

} 

} 

Come detto, è una classe che estende Textvìew e che definisce alcuni possibili stati personalizzati 
in base ai quali modifica il proprio background. Gli stati sono rappresentati da un array di interi che 
definiamo attraverso opportune costanti Nel costruttore impostiamo quindi il background facendo 
riferimento alla precedente risorsa di tipo Drawable. Essendo degli stati mutualmente esclusivi, 
abbiamo definito una serie di metodi set che permettono appunto di impostare ciascuno degli stati 
disabilitando tutti gli altri Tutta la logica è però implementata nel metodo onCreateDrawableState ( ) , 
che dovrà eseguire Emerge dei Drawable corrispondenti allo stato corrente. In particolare vediamo 
come venga aggiunto il valore 4 al numero di stati esistenti ottenuto come valore del parametro 
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extraspace e come venga utilizzato il metodo mergeDrawabiestates ( ) per la definizione dello sfondo 
da applicare. Ora il nostro componente è pronto e ne lasciamo la verifica al lettore all'interno di un 
layout di comodo. 



Inseriamo il componente in una finestra di dialogo 

Nella Figura 5.35 il nostro calendario è contenuto all'interno di una finestra di dialogo che abbiamo 

implementato nella classe CalendarChooserDialogFragment: 
public class CalendarChooserDialogFragment extends DialogFragment { 

private static final String TAG_LOG = CalendarChooserDialogFragment . class . getName () ; 

private static final String DATE_ARG_KEY = Const.PKG + " . args . DATE_ARG_KEY" ; 

public interface OnCalendarChooserListener { 

void dateSelected (CalendarChooserDialogFragment source, Date selectedDate) ; 

void selectionCanceled (CalendarChooserDialogFragment source); 

} 

private OnCalendarChooserListener mOnCalendarChooserListener; 

public static CalendarChooserDialogFragment getCalendarChooserDialog ( 
final Date currentDate) { 
CalendarChooserDialogFragment calendarChooserDialog = 

new CalendarChooserDialogFragment () ; 

Bundle args = new Bundlet); 
if (currentDate == nuli) { 

args .putLong (DATE_ARG_KEY, System. currentTimeMillis () ) ; 
} else { 

args . putLong (DATE_ARG_KEY, currentDate . getTime ( ) ) ; 

} 

calendarChooserDialog . setArguments (args) ; 
return calendarChooserDialog; 

} 

@Override 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 

if (activity instanceof OnCalendarChooserListener) { 

this .mOnCalendarChooserListener = (OnCalendarChooserListener) activity; 

} 

} 

public static CalendarChooserDialogFragment getCalendarChooserDialog ( ) { 
return getCalendarChooserDialog (nuli ) ; 

} 

@Override 

public Dialog onCreateDialog (Bundle savedlnstanceState) { 

final CalendarChooser calendarChooser = new CalendarChooser (getActivìty ()) ; 
final long dateAsLong = getArguments ( ) . getLong (DATE_ARG_KEY) ; 
calendarChooser. setCurrentDate (dateAsLong) ; 

AlertDialog . Builder builder = new AlertDialog . Builder (getActìvity () ) 
. setTitle (R. string. calendar_dialog_title ) 
. setview (calendarChooser) 

. setPositiveButton (R. string. calendar_yes_label, 

new Dialoglnterf ace . OnClickListener ( ) { 

SOverride 

public void onClìck (Dialoglnterf ace dialoglnterf ace, int i) { 
if (mOnCalendarChooserListener != nuli) { 
mOnCalendarChooserListener 

. dateSelected (CalendarChooserDialogFragment . this, 
calendarChooser . getCurrentDateAsDate () ) ; 
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} 

} 

}) 

. setNegativeButton (R. string. calendar_no_label, 

new Dialoglnterf ace . OnClickListener ( ) { 

@Override 

public void onClick (Dialoglnterf ace dialoglnterf ace, int i) { 
if (mOnCalendarChooserListener != nuli) { 
mOnCalendarChooser Li s tener 

. selectìonCanceled (CalendarChooserDialogFragment .this) ; 

} 

Log . d ( TAG_LOG, "Selection canceled"); 

} 

}) ; 

return builder . create () ; 

} 

} 

Anche qui non abbiamo fatto altro che applicare alcuni dei pattern di creazione dei fragment che 
abbiamo visto nel Capitolo 4. Abbiamo infatti definito un'interfaccia, di nome 
oncaiendarchooseriistener, per restituire il risultato all'eventuale activity e creato una Diaiog, 
contenente semplicemente il nostro componente, all'interno dell'implementazione del metodo 
onCreateDiaiog ( ) . Nel nostro esempio abbiamo utili/rato la versione a basso livello per cui 
chiediamo al lettore di integrare l'utilizzo della finestra di dialogo come esercizio oppure di attendere il 
prossimo paragrafo. A parte il nome della classe utilizzata, il funzionamento sarà esattamente lo stesso. 



Componente personalizzato di basso livello 

Come già accennato, abbiamo deciso di implementare anche una versione a basso livello, ovvero 
che utilizza le API che ci consentiranno di disegnare, nel vero senso della parola, il nostro calendario a 
ogni variazione del suo stato. La modalità di utilizzo sarà esattamente la stessa del caso precedente e 
si differenzierà solamente per il nome della classe e delle relative interfacce di notifica. Anche qui 
utilizziamo un layout di appoggio che è leggermente diverso (file 

widget_graph_calendar_chooser . xml), nel senso che si differenzia solamente perché la griglia delle 
date è completamente disegnata insieme all'elenco dei nomi dei giorni della settimana. Il disegno è 

Stato implementato all'interno della classe interna GraphCalendarChooser.CalendarGrid e 

precisamente nel metodo onDraw ( ) . Prima di questo vediamo però velocemente il seguente metodo: 

SOverride 

protected void onMeasure (int widthMeasureSpec, int heightMeasureSpec) { 

final int maxWeekNumber = mCurrentDate . getActualMaximum (Calendar .WEEK_OF_MONTH) ; 

DisplayMetrics dm = new DisplayMetrics ( ) ; 

final int daysHeight = (maxWeekNumber +1) * DAY_HEIGHT; 

int heightSpec = MeasureSpec . makeMeasureSpec (daysHeight , MeasureSpec . EXACTLY) ; 
setMeasuredDìmension (widthMeasureSpec, heightSpec) ; 

} 

che sappiamo essere invocato nella prima fase di gestione del layout ovvero quella durante la quale 
vengono chieste al componente le dimensioni desiderate. Nel nostro caso le dimensioni sono quelle 
assegnate per quello che riguarda la larghezza, mentre per l'altezza sono calcolate in base al numero 
di settimane che abbiamo la necessità di visualizzare. Tornando alla visualizzazione, il nostro metodo 
onDraw ( ) è implementato in questo modo: 

SOverride 

protected void onDraw (Canvas canvas) { 
super . onDraw (canvas ) ; 

final float itemWidth = (float) getWidth() / DAYS_IN_A_WEEK; 
canvas . drawRect ( 0 , 0, getWidth(), getHeight(), mBgPaint) ; 

final int f irstDaylnTheWeek = mCurrentDate . getFìrstDayOfWeek () ; 
final Calendar utilCalendar = Calendar . getlnstance () ; 
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for (int i = 0; i < DAYS_IN_A_WEEK; i++) { 

final int currentDay = ( f irstDaylnTheWeek + i) % DAYS_IN_A_WEEK; 
utilCalendar . set (Calendar . DAY_OF_WEEK, currentDay) ; 

final String shortDayName = DAY_IN_WEEK_FORMAT . format (utilCalendar . getTime ()) ; 
Rect textNameBounds = new Rect(); 
mDayNamesPaint . getTextBounds (shortDayName, 0, 

shortDayName . length ( ) , textNameBounds) ; 
int nameHeight = (int) (mDayNamesPaint . ascent ( ) - mDayNamesPaint . descent ()) ; 
int nameWidth = textNameBounds . width () ; 

final float nameX = i * itemWidth + (ìtemWidth - nameWidth) / 2; 

final float nameY = (DAY_HEIGHT - nameHeight) / 2; 

canvas . drawText (shortDayName, nameX, nameY, mDayNamesPaint); 

} 

final int maxWeekNumber = mCurrentDate . get ActualMaximum (Calendar .WEEK_OF_MONTH) ; 

final Calendar f irstOf TheMonth = Calendar . getlnstance () ; 

f irstOf TheMonth . setTime (mCurrentDate . getTime ( ) ) ; 

firstOf TheMonth. set (Calendar . DAY_OF_MONTH, 1) ; 

int firstDay = f irstOf TheMonth . get (Calendar . DAY_OF_WEEK) ; 

final int dayOffset = firstDay - f irstDaylnTheWeek; 

utilCalendar . setTime ( f irstOf TheMonth . getTime ( ) ) ; 

utilCalendar. add (Calendar. DATE, -1 * dayOffset); 

mFirstDateShown = Calendar . getlnstance () ; 

mFirstDateShown . setTime (utilCalendar . getTime ( ) ) ; 

final Calendar now = Calendar . getlnstance () ; 

final int today = now . get (Calendar . DAY_OF_YEAR) ; 

final int todayMonth = now . get (Calendar . MONTH) ; 

final int todayYear = now . get (Calendar . YEAR) ; 

final int selectedDay = mCurrentDate . get (Calendar . DAY_OF_YEAR) ; 
final int selectedMonth = mCurrentDate . get (Calendar . MONTH) ; 
final int selectedYear = mCurrentDate . get (Calendar . YEAR) ; 
for (int week = 0; week < maxWeekNumber; week++) { 
for (int i = 0; i < DAYS_IN_A_WEEK; i++) { 

final int dayToShow = utilCalendar . get (Calendar . DATE) ; 

final String dayAsString = String . valueOf (dayToShow) ; 

Rect textNameBounds = new Rect(); 

mDaysPaint . getTextBounds (dayAsString, 0, dayAsString . length () , 
textNameBounds) ; 

final int dayHeight = (int) (mDayNamesPaint . ascent ( ) 

- mDayNamesPaint . descent ()) ; 
final int dayWidth = textNameBounds . width () ; 
final float rectX = i * itemWidth; 
final float rectY = (week +1) * DAY_HE I GHT ; 

final int dayX = (int) ( (i * ìtemWidth) + (ìtemWidth - dayWidth) / 2); 

final int dayY = (week + 1) * DAY_HEIGHT + (DAY_HEIGHT - dayHeight) / 2; 

final int currentDaylnYear = utilCalendar . get (Calendar . DAY_OF_YEAR) ; 

final int currentMonthYear = utilCalendar . get (Calendar .MONTH) ; 

final int currentYear = utilCalendar . get (Calendar . YEAR) ; 

if (selectedDay == currentDaylnYear && selectedYear == currentYear) { 

mCurrentDayBgPaint . setColor (mBgColorSelected) ; 
} else if (today == currentDaylnYear && todayYear == currentYear) { 

mCurrentDayBgPaint . setColor (mBgTodayColor) ; 
} else if (currentMonthYear == selectedMonth) { 

mCurrentDayBgPaint . setColor (mBgColorThisMonth) ; 
} else { 

mCurrentDayBgPaint . setColor (mBgColorOtherMonth) ; 

} 

canvas .drawRect (rectX, rectY, rectX + itemWidth, 

rectY + DAY_HE IGHT , mCurrentDayBgPaint) ; 
canvas .drawText (dayAsString, dayX, dayY, mDaysPaint); 

utilCalendar . add (Calendar . DATE, 1) ; 

} 

} 

} 

Il lettore potrà notare come in questa implementazione non vi sia alcuna aggiunta di view particolari 
ma il tutto venga disegnato. In questo modo la quantità di memoria utilizzata è sicuramente minore 
rispetto al caso precedente in cui, a ogni aggiornamento, dovevamo rimuovere e poi ricreare una 
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struttura ad albero piuttosto impegnativa. Questa soluzione di basso livello olire prestazioni superiori, 
oltre che una maggiore libertà di personalizzazione grafica. Il prezzo da pagare è un codice più 
complesso e la necessità di gestire gli eventi in modo specifico, come descritto nel paragrafo 
successivo. 

Anche per questa implementazione abbiamo implementato il corrispondente hragmentDiaiog 
attraverso il seguente codice, che ormai dovrebbe essere di semplice lettura: 

public class CalendarGraphChooserDialogFragment extends DìalogFragment { 

private static final String TAG_LOG = 
CalendarGraphChooserDialogFragment . class . getName ( ) ; 

private static final String DATE_ARG_KEY = Const.PKG + " . args . DATE_ARG_KEY" ; 

public interface OnGraphCalendarChooserListener { 

void dateSelected (CalendarGraphChooserDialogFragment source, Date selectedDate) ; 

void selectionCanceled (CalendarGraphChooserDialogFragment source) ; 

} 

private OnGraphCalendarChooserListener mOnGr aphCalendarChooser Li s tener; 

public static CalendarGraphChooserDialogFragment 

getCalendarChooserDialog ( final Date currentDate) { 
CalendarGraphChooserDialogFragment calendarChooserDialog = 

new CalendarGraphChooserDialogFragment () ; 

Bundle args = new BundleO; 
if (currentDate == nuli) { 

args .putLong (DATE_ARG_KEY, System. currentTimeMillis () ) ; 
} else { 

args . putLong (DATE_ARG_KEY, currentDate . getTime ( ) ) ; 

} 

calendarChooserDialog . setArguments (args) ; 
return calendarChooserDialog; 

} 

SOverride 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 

if (activity instanceof OnGraphCalendarChooserListener) { 
this .mOnGraphCalendarChooserListener = 

(OnGraphCalendarChooserListener) activity; 

} 

} 

public static CalendarGraphChooserDialogFragment getCalendarChooserDialog ( ) { 
return getCalendarChooserDialog (nuli ) ; 

} 

@Override 

public Dialog onCreateDialog (Bundle savedlnstanceState) { 
final GraphCalendarChooser calendarChooser = 
new GraphCalendarChooser (getActivity () ) ; 

final long dateAsLong = getArguments ( ) . getLong (DATE_ARG_KEY) ; 
calendarChooser . setCurrentDate (dateAsLong) ; 

AlertDialog . Builder builder = new AlertDialog . Builder (getActivity () ) 
. setTitle (R. string. calendar_dialog_title ) 
. setview (calendarChooser) 

. setPositiveButton (R. string. calendar_yes_label, 

new Dialoglnterf ace . OnClickListener ( ) { 

SOverride 

public void onClick (Dialoglnterf ace dialoglnterf ace, int i) { 
if (mOnGraphCalendarChooserListener != nuli) { 
mOnGr aphCalendarChooser Li s tener 

. dateSelected (CalendarGraphChooserDialogFragment .this, 
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calendarChooser . getCurrentDateAsDate () ) ; 

} 

} 

}) 

. setNegativeButton (R. string. calendar_no_label, new 
Dialoglnterface. OnClickLis tener ( ) { 
SOverride 

public void onClick (Dialoglnterface dialoglnterface, int i) { 
if (mOnGraphCalendarChooserListener != nuli) { 

mOnGraphCalendarChooserLis tener . selectionCanceled (CalendarGraphChooserDialogFragment . this) 

} 

} 

}) ; 

return builder . create () ; 

} 

} 

Notiamo come si tratti della stessa implementazione del caso precedente in cui abbiamo 
semplicemente utilizzato ilGraphCaiendarChooser e le corrispondenti interfacce listener. 

L'uso di questa classe nella nostra applicazione prevede alcune modifiche della classe 
RegisterActivity, da un lato legate all'utilizzo dei fragment e dall'altro all'implementazione 
dell'interfaccia di callback. Le parti modificate sono le seguenti: 

public class RegisterActivity extends FragmentActivity implements 
CalendarGraphChooserDialogFragment . OnGraphCalendarChooserListener { 

private static final DateFormat BIRTH_DATE_FORMAT = new SimpleDateFormat ( "dd MMMM 

yyyy") ; 

public static final String BIRTH_DATE_KEY = Const.PKG + " . extra . BIRTH_DATE_KEY" ; 
private TextView mBirthdateTextView; 
private Date mSelectedBirthDate; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 



//La BirthDate corrente 

if (savedlnstanceState == nuli) { 

mSelectedBirthDate = new DateO; 
} else { 

mSelectedBirthDate = new DateO; 

final long savedBirthDate = savedlnstanceState . getLong (BIRTH_DATE_KEY, 
System . currentTimeMillis ( ) ) ; 

mSelectedBirthDate . setTime (savedBirthDate) ; 

} 

} 

public void selectDate (View button) { 

CalendarGraphChooserDialogFragment dateDialog = 
CalendarGraphChooserDialogFragment . getCalendarChooserDialog (mSelectedBirthDate) ; 

dateDialog. show (getSupportFragmentManager () , "DATE SELECTION TAG"); 

} 

@Override 

protected void onSavelnstanceState (Bundle outState) { 
super . onSavelnstanceState (outState) ; 

outState .putLong (BIRTH_DATE_KEY, mSelectedBirthDate . getTime ( ) ) ; 

} 

SOverride 

public void dateSelected (CalendarGraphChooserDialogFragment source, 

Date selectedDate ) { 
this . mSelectedBirthDate = selectedDate; 
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mBirthdateTextView. setText (BIRTH_DATE_FORMAT . format (mSelectedBirthDate) ) ; 

} 

SOverride 

public void selectionCanceled (CalendarGraphChooserDialogFragment source) { 
} 

} 

Abbiamo infatti eliminato il DatePicker e tutto ciò che lo riguardava e messo al suo posto una 
semplice Textview per la visualizzazione della data corrente, insieme a un pulsante per la 
visualizzazione del CalendarGraphChooserDialogFragment . Per l'utilizzo del fragment abbiamo 
dovuto estendere la classe FragmentActivity e quindi implementare l'interfaccia 

OnGraphCalendarChooserListener. Nelmetodo di Callback dateSelected ( ) non abbiamo fatto altro 

che aggiornare la data di nascita memorizzata neU'activity. L'ultimissima osservazione riguarda la 
necessità di salvare il valore di questa data dalle possibili rotazioni del dispositivo attraverso il 
meccanismo ormai a noi noto. 

La gestione degli eventi 

Concludiamo questo capitolo osservando come le due implementazioni portino a una gestione degli 
eventi diversa. La prima è molto semplice in quanto prevede la semplice registrazione di un 
onciickListener su ciascun oggetto di tip o DayTextview che contiene, come proprietà, il riferimento 
al giorno a cui lo stesso è associato. Il secondo invece è più complesso e precede il calcolo del giorno 
selezionato a partire dalle coordinate del punto toccato. In particolare vediamo come sia stato 
necessario implementare il seguente metodo: 

@Override 

public boolean onTouchEvent (MotionEvent event) { 
float touchedx = event . getx () ; 
float touchedY = event. getYO - DAY_HEIGHT; 
int action = event . getAction () ; 

final float itemWidth = (float) getwidth() / DAYS_IN_A_WEEK; 
final int touchedCols = (int) (touchedx / itemWidth) ; 
final int touchedRows = (int) (touchedY / DAY_HEIGHT) ; 
final int offset = touchedCols + touchedRows * DAYS_IN_A_WEEK; 
//int offset = (int) ((touchedx / itemWidth) + (touchedY / DAY_HEIGHT) * 
DAYS_IN_A_WEEK) ; 

switch (action) { 

case MotionEvent . ACTION_DOWN : 

mMovingDate . setTime (mFirstDateShown . getTime ( ) ) ; 

mMovingDate . add (Calendar .DATE, offset) ; 

mCurrentDate = mMovingDate; 

postlnvalidate () ; 

break; 

case MotionEvent .ACTION_MOVE : 

if (! mMovingDate . equals (mCurrentDate) ) { 
/ / Aggiorniamo la data 
mCurrentDate = mMovingDate; 
postlnvalidate () ; 

} 

break; 

case MotionEvent .ACTION_UP : 

break; 
default : 

} 

return true; 

} 

A seconda del tipo di evento non abbiamo fatto altro che modificare la data corrente e poi 
richiedere, attraverso il metodo postlnvalidate o , ilrefresh della UI all'interno delthread principale 
dell'applicazione, come vedremo meglio nel Capitolo 9, dedicato al multithreading. 
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Conclusioni 

Siamo giunti al termine di questo capitolo molto impegnativo che ci ha permesso di vedere a fondo 
le classi view e viewGroup, che sono quelle da cui derivano tutti gli altri componenti per il cui utilizzo 
specifico rimandiamo alla documentazione ufficiale. Con il pretesto di sistemare la nostra applicazione 
abbiamo visto quali sono i layout principali e come applicarli Con il tentativo, probabilmente non 
riuscito, di abbellire la nostra applicazione abbiamo visto come utilizzare gli stili e i temi, che abbiamo 
poi utilizzato per riprodurre lo stesso tema nelle varie schermate senza lunghe e pericolose operazioni 
di copia e incolla. Abbiamo poi concluso con la realizzazione di due componenti personalizzati non 
banali che ci hanno permesso di riprendere la gestione delle finestre di dialogo e dei fragment. Siamo 
ora pronti per affiontare un altro fondamentale argomento che è quello degli adapter e delle 
Listview, a cui è dedicato il prossimo capitolo. 



241 



Capitolo 6 



ListView e adapter 



Nel Capitolo 5 abbiamo studiato due classi fondamentali nella realizzazione delle applicazioni 
Android, ovvero la classe View e la classe ViewGroup. Abbiamo visto che la seconda è una particolare 
specializzazione della prima che aggrega altre view decidendo come disporle al proprio interno 
attraverso un meccanismo che utilizza le due fasi di measuring e layout. Abbiamo poi visto come il più 
semplice di questi layout sia il LinearLayout, che permette di posizionare le view che contiene 
secondo uno schema orizzontale o verticale a seconda del valore della sua proprietà orientation. A 
questo punto però ci poniamo una domanda: qual è il layout migliore da utilizzare nel caso in cui 
dovessimo visualizzare un elenco di informazioni anche molto lungo se non teoricamente infinito? Una 
prima risposta potrebbe essere quella di utilizzare una soroiiview all'interno della quale inserire un 
LinearLayout contenente tutte le view relative ai dati da visualizzare. Peccato però che una soluzione 
di questo tipo sarebbe completamente inefficiente, in quanto richiederebbe la creazione di un numero 
esagerato di istanze relative anche a dati che magari in un determinato momento non sono visibili 
perché lontani dalla posizione dell'elenco visualizzato. Servirebbe quindi un meccanismo che 
permettesse di creare solamente il numero di view che servono alla visualizzazione di ciò che 
effettivamente si vede, ed eventualmente riutilizzarle nel caso in cui avessimo bisogno di far scorrere la 
nostra lista. Fortunatamente un meccanismo di questo tipo è già disponibile e sarà l'argomento di 
questo capitolo. Vedremo infatti come funziona una Listview e come la stessa possa interagire con 
quello che si chiama adapter, che è un' astrazione del componente in grado di accedere alle 
informazioni e di creare le view per la loro visualizzazione nella lista. Dopo una descrizione generica di 
questi componenti, vedremo come gli stessi vengono utilizzati all'interno di un'activity e di un fragment 
per poi applicare il tutto alla nostra app Reazione UGHO. In particolare visualizzeremo i dati relativi 
alle informazioni locali e/o remote come descritto nelle corrispondenti attività. 



ListView e adapter 

Prima di addentrarci negli esempi relativi alle diverse implementazioni, è sempre bene fare un 
minimo di introduzione su quelli che sono i concetti alla base di questi componenti fondamentali. Un 
adapter è una particolare interfaccia del package android . widget che descrive un' astrazione la cui 
responsabilità è quella di disaccoppiare la modalità di acquisizione dei dati dalla loro visualizzazione. 
Per chi ha esperienza nello sviluppo di applicazioni enterprise si fa spesso un' analogia tra un adapter e 
il DAO (Data Access Object), in quanto si tratta di pattern con caratteristiche molto simili. La 
differenza sostanziale sta nel fatto che, mentre un DAO si occupa solamente di dati, un adapter (nel 
senso Android) ne fornisce anche le possibili rappresentazioni. 

NOTA 

Il nome adapter non è casuale in quanto rappresenta un richiamo a un altro design pattern questa 
volta della GoF ( Gang of Four ), che permette di mettere in comunicazione due oggetti con 
interfacce diverse e quindi non direttamente compatibili. 
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Mentre un DAO ha un insieme di operazioni tipiche di un CRUD (Create, Retrìeve, Update e 
Delete) del tipo f indByid ( ) , update ( ) e delete ( ) , un adapter ha come sua operazione principale 
quella descritta dalla seguente riga: 

public abstract View getview (int posìtion, View convertview, ViewGroup parent) 

che notiamo gestire componenti di tipo view che ferino riferimento alla modalità di visualizzazione 
del dato. Possiamo quindi dire che un adapter è qualunque componente la cui responsabilità è quella 
di reperire delle informazioni da una base dati e di fornire, per ciascuna di esse, una rappresentazione 
attraverso ima particolare specializzazione della classe view, che sappiamo essere la generalizzazione 
di ogni elemento della UI da inserire all'interno di un'activity. Per restare in tema di design pattern, 
ricordiamo che anche ilviewGroup non è altro che l'applicazione di un pattern GoF che si chiama 
Composite (Figura 6.1). Come possiamo vedere un viewGroup è una particolare specializzazione 
della classe view che ha come responsabilità quella di ridimensionare e posizionare al proprio interno 
le view che contiene. La potenza del pattern sta nel fatto che essendo viewGroup una particolare view, 
potrà essere contenuto a sua volta all'interno di un altro viewGroup e così via. Si tratta dello stesso 
meccanismo alla base dei layout. 

Un viewGroup è una particolare view con responsabilità di layout. Una particolare specializzazione 
di ViewGroup potrebbe aggregare, e quindi visualizzare, in modo diverso un insieme di view che gli 
vengono fornite da un particolare adapter. Stiamo parlando della classe AdapterView, che implementa 
tutta la logica di collaborazione tra un viewGroup e un adapter. 



View 



Attributes <i 



Operations 



j ViewGroup 



Attributes 
views : Collection<View> 



Operations 
+ doLayout( ) : void 



i Specifica View 



Attributes 



Operations 
+ onDraw( ) : void 



for(View v: views) 
v.onDrawO; 



Figura 6.1 Implementazione del pattern Composite. 

Come accennato, una specializzazione di AdapterView potrà visualizzare in modo diverso le view 
che gli vengono fornite da una particolare implementazione di un adapter che preleva le informazioni 
da una base dati e ne fornisce le possibili rappresentazioni visuali Siamo così giunti alla Listview, una 
specializzazione della classe AdapterView che visualizza le view fornite da un adapter secondo una 
modalità a lista che si può fer scorrere verticalmente. In realtà una Listview utilizza una ulteriore 
specializzazione di adapter che si chiama ListAdapter e che aggiunge alla precedente solamente le 
informazioni relative all'abilitazione o meno delle view, come possiamo vedere dal diagramma delle 
classi nella Figura 6.2. 
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Il lettore avrà compreso come la gestione delle informazioni da visualizzare in corrispondenza di 
ogni elemento di ima lista avvenga attraverso la realizzazione di particolari implementazioni di adapter 
ottenute specializzando quelle esistenti, specialmente per quello che riguarda la parte di 
visualizzazione. Nei prossimi paragrafi ci occuperemo di questo importante componente descrivendo, 
nel dettaglio, i principali casi d'uso, dal più semplice al più complesso. 



Gli adapter nel dettaglio 

Per comprendere a fondo che cos'è un adapter è importante fornire una descrizione di quelle che 
sono le operazioni principali descritte dall'omonima interfaccia nel package android.widget. Si tratta 
infatti delle operazioni che ogni implementazione dovrà fornire e che ci permetteranno di comprendere 
a fondo anche i meccanismi di personalizzazione delle Listview. Come dice il nome stesso, si tratta di 
un componente la cui responsabilità è quella di disaccoppiare (adattare) la sorgente dei dati da quello 
che è il componente responsabile alla loro visualizzazione. Alla base di ima lista vi è il concetto di 
posizione. Il primo elemento avrà posizione 0, mentre l'ultimo avrà posizione corrispondente al 
numero di elementi - 1 . 



LdViewGroup 



Attributes 
views : Collection<View> 



Operations 
+ doLayout( ) : void 

2 



_i ViewAdapter 

Attributes 



Operations 

2 




«interface» 
r Adapter 



Operations 

+ getCount( ) : int 

+ getltem( position : int ) : Object 

+ getltemld( position : int ) : long 

+ getltemViewType( position : int ) : int 

+ getViewTypeCount( ) : int 

+ hasStablelds( ) : boolean 

+ isEmpty( ) : boolean 

+ registerDataSetObseiver( o : DataSetObserver ) : void 
+ unregisterDataSetObserver( o : DataSetObserver) : void 
+ getView( position : int, cv : View, p : ViewGroup ) : View 



y ListView 



Attributes 



Operations 



uses 



«interface» 
ho ListAdapter 



Operations 
+ areAllltemsEnabled( ) : boolean 
+ isEnabled( position : int ) : boolean 



Figura 6.2 Relazione tra una ListView e un ListAdapter. 

Per questo motivo, ogni implementazione di adapter dovrà ritornare il riferimento all'oggetto di cui 
dovrà fornire una rappresentazione in una data posizione, attraverso questa operazione: 

public abstract Object getltem(int position) 

Qui il tipo di ritorno è object, mentre alcune specializzazioni, come vedremo, saranno descritte da 
classi generiche. Un'altra operazione molto importante è invece la seguente: 

public abstract long getltemld (int position) 

che ritorna, per ogni posizione, l'identificatore dell'elemento associato. E un'informazione che 



244 



dipende dal tipo di implementazione. Per esempio, nel caso in cui l'adapter fosse implementato a 
partire da un array, l'identificatore di un elemento sarebbe la sua posizione all'interno dell' array 
stesso, e quindi il valore di position. In altre implementazioni che invece estraggono le informazioni 
da un DB, il valore ritornato sarebbe il corrispondente id o comunque il valore del campo 
equivalente. 
NOTA 

Si potrebbe obiettare sul fatto che il tipo di tale valore sia long ma, come vedremo, questo è il tipo 
dell'identificatore degli elementi all'interno di quello che si chiama content provider e che 

impareremo a creare e utilizzare nel Capitolo 8. 

Sempre rispetto agli identificatori di un particolare elemento, ogni adapter dovrà fornire 
l'implementazione di questa operazione: 

public abstract boolean hasStablelds ( ) 

che permette di sapere se gli identificatori dei vari elementi possono cambiare a seguito delle 
variazioni dei dati contenuti. Questa informazione sarà molto probabilmente utilizzata in fase di 
ottimizzazione delle performance al fine di evitare ripetizioni di calcoli dispendiosi durante la 
visualizzazione. 

Ogni implementazione di adapter dovrà poi dare indicazione sul numero di elementi da visualizzare 
e poi implementare due operazioni: 

public abstract ìnt getCountO 
public abstract boolean isEmptyO 

La seconda è più che altro un metodo di utilità che non fa altro che verificare se il valore ritornato 
da getcount ( ) è pari a 0 oppure no. 

Le operazioni più interessanti riguardano invece la gestione delle view e tra queste la più importante 
è sicuramente la seguente: 

public abstract View getview(int position, View convertview, ViewGroup parent) 

Il compito di questo metodo è quello di ottenere e poi ritornare la view per la rappresentazione del 
dato di posizione specificata dal valore del parametro position. Quello che rende però questa 
operazione interessante sono gli altri parametri Quello di nome convertview è il riferimento a una 
view eventualmente già utilizzata per la visualizzazione di un valore che non è più visibile. Supponiamo 
infatti di avere una lista di elementi e una particolare istanza di view che visualizza il primo elemento, 
ovvero quello in posizione 0. Supponiamo poi che la lista stia visualizzando 10 elementi Se ora la 
facciamo scorrere verso il basso con l'intenzione di visualizzare gli elementi successivi noteremo 
come quello in posizione 0 sparisca per mostrare, nello specifico, quello in posizione 10 (le posizioni 
iniziano a 0, per cui il decimo aveva posizione 9). Questo è un caso tipico in cui la view che prima 
visualizzava l'elemento nella posizione 0 può essere riciclata per la visualizzazione di quello in 
posizione 10. Accade quando il riferimento passato al metodo getview O attraverso il parametro 
convertview non è nullo e quindi possiamo in un certo senso riutilizzarlo senza dover necessariamente 
istanziare nuovi oggetti. 

NOTA 

Sebbene, per la creazione di codice leggibile, non sia una buona norma quella di programmare da 
subito con l'obiettivo di ottenere performance elevate, è bene sapere che la creazione di nuove 
istanze è un'operazione relativamente pesante per un dispositivo mobile per cui è consigliabile 
limitarne il numero. 

Sarà cura del particolare adapter verificare la validità, e soprattutto la presenza, ditale view prima 
del suo riutilizzo. Il terzo parametro, di nome parent, è un oggetto di tipo vìewGroup che andrà a 
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contenere le view create. Nella realtà è un parametro che non si utilizza molto spesso ma che può 
essere utile per ottenere le informazioni di layout. Nella maggior parte delle implementazioni del 
metodo get view ( ) non èremo altro che eseguire V inflette di un particolare layout e mappare i dati sui 
diversi elementi dello stesso. 
NOTA 

Ricordiamo che Untiate è quell'operazione che permette di creare un'istanza di una particolare view 
a partire da un documento XML che la descrive in modo dichiarativo. Esiste il Layoutmtiater per 
Untiate di documenti di layout ma anche il Menumfiate per la creazione di oggetti di tipo Menu come 
vedremo in seguito. 

Una prima obiezione del lettore attento potrebbe essere relativa al fatto che potremmo avere 
l'esigenza di avere delle view differenti per i diversi elementi della lista. Esse potrebbero infatti essere 
diverse non solo per aspetti legati ai colori o sfondi (cosa risolvibile attraverso l'applicazione di 
opportuni stili) ma piuttosto in relazione al layout e alle informazioni visualizzate. Per quanto visto fino 
a ora, ogni adapter sarebbe costretto e verificare che la view da riutilizzare fosse del tipo compatibile 
con rinformazione da visualizzare. In caso positivo saremmo in grado di riutilizzarla ma in caso 
negativo dovremo creare comunque una nuova istanza. Fortunatamente l'interfaccia adapter prevede 
la gestione di uno scenario di questo tipo attraverso la definizione delle seguenti operazioni; 

public abstract int getViewTypeCount ( ) 

public abstract int getltemViewType (int position) 

La prima operazione dovrà ritornare il numero di tipi di View diverse. Il valore di default è 1 ma nel 
caso in cui vi fossero tre diverse modalità di visualizzazione di ima riga attraverso l'utilizzo di tre 
diverse layout, per esempio, il valore ritornato dovrà essere 3. La seconda operazione dovrà invece 
indicare a quale di questi tipi di view fare riferimento per l'elemento in una data posizione indicata 
attraverso il parametro position. Se le possibili view fossero tre allora i valori di ritorno da questo 
metodo sarebbero 0, 1 oppure 2. In realtà esiste sempre la possibilità di un quarto valore relativo alla 
costante Adapter . ignore_item_view_type, che permette di indicare al contenitore di ignorare questa 
informazione e non abilitare il riutilizzo della view; qui il valore del parametro convertView Sarà nuli e 
quindi la view dovrà essere creata come fosse nuova. Il vantaggio di questi due metodi sta nel fatto 
che, in caso di riciclo, il tipo di view ottenuta attraverso il parametro convertview sarà sempre del 
tipo compatibile con quello relativo alla posizione corrente. Se l'elemento nella posizione X è di tipo 
1 , la view associata al parametro convertview Sarà dello stesso tipo o nuli se non presente. 

Infine, che cosa succede nel caso in cui i dai visualizzati dovessero essere modificati? Per gestire 
questo caso, ogni adapter dovrà implementare queste operazioni: 

public abstract void registerDataSetObserver (DataSetObserver observer) 
public abstract void unregisterDataSetObserver (DataSetObserver observer) 

e permettere a un oggetto che implementa l'interfaccia DataSetObserver di ricevere notifiche 
relativamente alla variazione dei dati gestiti Si tratta di operazioni che permetteranno, per esempio, 
alla List view di aggiornarsi e quindi visualizzare dati consistenti 

Come funziona la ListView 

Per descrivere nel dettaglio cos'è ima Listview facciamo un breve riassunto dei concetti esaminati 
fin qui Come prima cosa abbiamo visto come la classe view rappresenti un' astrazione di tutti quei 
componenti che visualizzano delle informazioni e ne permettono l'interazione con l'utente attraverso 
una gestione accurata degli eventi Abbiamo poi esaminato un tipo particolare di view che ha come 
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responsabilità quella di disporre al suo interno altre view secondo un particolare algoritmo definendo 
così la classe viewGroup. Abbiamo poi visto come particolari specializzazioni di questa classe 
permettano l'implementazione di layout più o meno complessi. Abbiamo infine introdotto il concetto di 
adapter come quell'oggetto che, accedendo a diversi tipi di informazioni, costruisce le view per la 
loro rappresentazione. 

Supponiamo di creare una specializzazione diviewGroup la cui responsabilità è quella di 
visualizzare sullo schermo, in un modo ancora non precisato, le view fornite da un particolare adapter 
che accede a una sorgente di dati Questa classe esiste e si chiama AdapterView. Se andiamo a 
osservare la documentazione, vediamo come si tratti di una classe astratta che quindi dovrà essere 
interiormente specializzata. Questo proprio perché implementa la logica di comunicazione tra un 
viewGroup e un adapter senza specificare gli aspetti legati alla disposizione delle view sul display, 
ovvero gli aspetti di layout. Sarà responsabilità delle sue specializzazioni dire se le view ottenute 
dall' adapter debbano essere disposte in una lista, in una griglia o in altro modo. La principale 
specializzazione della classe AdapterView è appunto Listview, che dispone le view che ottiene da un 
adapter all'interno di una lista. A questo punto non ci resta che usare quanto descritto nella nostra 
applicazione cercando di esaminare tutte le possibili implementazioni di adapter. 



Sistemiamo la base dati di UGHO 

Prima di iniziare la creazione delle liste relative alle informazioni locali o remote (che al momento 
considereremo allo stesso modo) all'interno di una lista, diamo una sistemata a quella che è la base 
dati della nostra applicazione. Al momento abbiamo infatti gestito solamente quello che riguardava le 
informazioni dell'utente attraverso la classe userModei e abbiamo accennato a un sistema di 
registrazione e login. Per quello che riguarda la visualizzazione delle informazioni, nella lista abbiamo 
creato una struttura temporanea che poi nei prossimi capitoli miglioreremo in base a quello che 
decideremo essere la nostra base dati locale e quello che invece dovremo ottenere dal server per i 
dati remoti. La prima lista che realizzeremo sarà quella relativa ai dati locali, la quale dovrà 
visualizzare, per ogni giorno, i voti inseriti per le quattro categorie. Abbiamo definito la seguente classe 

LocalDataModel 

public final class LocalDataModel { 
public final long id; 
public final long entryDate; 

public final int loveVote; 
public final int healthVote; 
public final int workVote; 
public final int luckVote; 

private LocalDataModel (final long id, final long entryDate, 
final int loveVote, final int healthVote, 
final int workVote, final int luckVote) { 
this.id = id; 

this . entryDate = entryDate; 
this . loveVote = loveVote; 
this . healthVote = healthVote; 
this . workVote = workVote; 
this . luckVote = luckVote; 

} 

public static LocalDataModel create (final long id, final long entryDate, 
final int loveVote, final int healthVote, 
final int workVote, final int luckVote) { 
return new LocalDataModel (id, entryDate, loveVote, 

healthVote, workVote, luckVote) ; 
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} 

} 

È una classe che non ha molte particolarità se non quella di avere tutti gli attributi pubblici In 
questo caso non ci sono pericoli di modifica incontrollata dei valori in quanto si tratta di membri final 
che quindi non possono più cambiare il proprio valore dopo l'esecuzione del costruttore. Nel nostro 
caso abbiamo utilizzato uno static factory method che ha impedito alle eventuali istanze di assumere 
stati non consistenti Questo significa che quando viene creata un'istanza della classe LocalDataMode, 
tutti i suoi valori sono stati inizializzati e non possono più essere modificati Abbiamo così creato una 
classe che permette la creazione di oggetti immutabili molto importanti come vedremo, specialmente 
in un contesto multithreading. 

Per simulare in qualche modo la nostra sorgente di dati abbiamo poi creato la classe astratta di 
nome LocaivoteService, che definisce la seguente operazione: 

public abstract VoteTransf erOb ject IoadVotes (final int start, final int length); 

la quale ritorna un'istanza di un oggetto di tipo voteTransferObject, che è l'implementazione di un 
pattern J2EE che si chiama appunto Transf erOb ject e che permette di aggregare tra loro oggetti di 
tipo diverso al fine di ottimizzarne il trasferimento. Abbiamo utilizzato questa classe per simulare quello 
che è il caricamento progressivo di informazioni attraverso una sorta di paginazione. La classe 
voteTransferObject è stata definita come classe statica interna come segue: 

public final class VoteTransferObject { 

public final int mFirst; 
public final int mLength; 

public final int mTotal; 

public final List<LocalDataModel> mData; 

public VoteTransferObject (final List<LocalDataModel> data, 

final int first, final int length, final int total) { 
this. mData = data; 
this. mFirst = first; 
this. mLength = length; 
this. mTotal = total; 

} 

} 

Utilizzando lo stesso meccanismo di prima relativamente all'immutabilità, si tratta di un oggetto che 
contiene alcune informazioni oltre a dei metadati relativi alla loro paginazione. Tra questi abbiamo il 
numero totale di elementi e quindi il primo e il numero di quelli memorizzati in quel momento. 

Per semplificare il tutto abbiamo creato una prima specializzazione di LocaivoteService che ci 
permetterà di verificare il funzionamento delle nostre Listview. Si tratta di un'implementazione che 
ritorna alcune paginazioni di un numero massimo di 100 elementi. I voti vengono generati in modo 
casuale a ogni richiesta. 

La lista più semplice 

Come detto il nostro primo obiettivo è quello di creare la schermata relativa alla visualizzazione dei 
voti locali che l'utente ha dato giorno per giorno, all'interno di una lista e quindi di una Listview. 

NOTA 

In questo paragrafo creeremo delle activity e dei fragment che il lettore potrà testare modificando 
rispettivamente la dichiarazione all'interno del file di configurazione LidroidManifest.xmi oppure il nome 
della classe relativa al fragment da utilizzare all'interno dell'activity contenitore. 
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La prima implementazione si ottiene semplicemente creando un layout che contiene una Listview 
di cui si ottiene un riferimento per assegnare una particolare implementazione di adapter. Abbiamo 
realizzato il layout simpie_iist_iocai_data . xml. Come possiamo vedere è un layout molto semplice 
che contiene un FrameLayout con all'interno una Listview. Per tare questo utilizziamo il layout editor 
e trasciniamo il componente Listview dalla palette alla preview della nostra interfaccia ottenendo 
quanto mostrato nella Figura 6.3. 
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Figura 6.3 Creazione di un layout contenente una ListView. 



Come possiamo notare la preview visualizza un elenco di ipotetici elementi caratterizzato da un 
layout su due righe. In realtà questo non è il layout che verrà utilizzato nell'applicazione ma un'opzione 
dell'editor per avere una preview di quello che possiamo ottenere. Possiamo infatti modificare il 
layout da associare a ogni riga nella preview selezionando la lista con il tasto destro del mouse e 
quindi selezionando l'opzione Preview List Content e poi il layout che utilizzeremo per primo, cioè 
quello associato al nome Simple List Item, come possiamo vedere nella Figura 6.4. 
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Figura 6.4 Opzione per la gestione della preview per il layout di riga di una ListView. 

Nella figura vediamo come si possono scegliere dei layout predefiniti (a cui potremo fare 
riferimento attraverso le costanti della piattaforma android.R. layout) oppure un layout diverso, 
come faremo in un esempio successivo. Scegliendo l'opzione selezionata il risultato sarà quello della 
Figura 6.5. 
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Figura 6.5 Previewche utilizza il layout di riga android.R. layout. simpleJayout_list_1 . 

Il corrispondente documento di layout sarà il seguente, dove abbiamo evidenziato quelle che sono 
le informazioni utilizzate dal tool per le preview ma che poi, ripetiamo, non saranno utilizzare 
dall'applicazione; ciò che verrà mostrato dipenderà infatti dall'implementazione dell' adapter: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/res/ android" 
xmlns : tools="http : //schemas . android. com/tools" 

android : layout_width="match_parent " 
android : layout_height="match_parent " > 

<ListView 

android: layout_width="wrap_content " 
android: layout_height="wrap_content " 
android : id=" @+id/listView" 
android: layout_gravity=" center" 

tools : listitem="@android: layout/simple_list_item_l" /> 

</FrameLayout> 

Sappiamo che è sempre bene assegnare un id a ogni componente di un layout; qui manteniamo 
quello assegnato in modo automatico, che è quello associato alla costante R. id. listview. c 
un'informazione che utilizzeremo nella nostra activity per ottenerne il riferimento. Il nostro primo 
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esempio utilizza l'activity descritta dalla classe SimpleLocalDataActivity 
public class SimpleLocalDataActivity extends FragmentActivity { 

private ListView mListView; 

private ArrayAdapter<LocalDataModel> mAdapter; 

private List<LocalDataModel> mModel = new LìnkedList<LocalDataModel> ( ) ; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . simple_list_local_data) ; 
mListView = (ListView) f indViewByld (R. id. listView) ; 
mAdapter = new ArrayAdapter<LocalDataModel> (this, 

android . R . layout . simple_list_item_l , mModel) ; 
mListView . setAdapter (mAdapter) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 

final LocalVoteService .VoteTransferObject result = 

LocalVoteService . sLocalVoteService . IoadVotes (0, 100) ; 
mModel . clear ( ) ; 
mModel . addAll (result . mData) ; 
mAdapter . notif yDataSetChanged ( ) ; 

} 

} 

All'interno del metodo onCreate o non tacciamo altro che ottenere il riferimento alla Listview per 
assegnarle come adapter un'istanza della classe ArrayAdapter. La classe ArrayAdapter descrive 
infatti quella che è l'implementazione più semplice di adapter che prende le informazioni da 
visualizzare all'interno di un array oppure di una lista come nel nostro caso. Notiamo come sia stata 
creata una lista inizialmente vuota e poi, attraverso l'accesso ai dati simulato con il servizio 
LocalVoteService, tale lista sia stata valorizzata all'interno del metodo onstart o . Non esiste 
nelT adapter un metodo che permette di aggiornare il modello associato, per cui dobbiamo modificare 
i dati contenuti in quello esistente. Importante è poi l'invocazione del metodo 
notif yDataSetChanged ( ) , che di fatto dice all' adapter di avvisare la view che lo sta utilizzando della 
modifica dei propri dati da cui l'aggiornamento della ListView. Vediamo poi come il layout utilizzato 
in fase di creazione dell' adapter sia quello associato alla costante 

android . R . layout . simple_list_item_l. 
NOTA 

Il lettore potrà notare come esistano diversi altri tipi di layout per la creazione di liste di vario tipo a 
selezione singola, multipla e così via. Per questi dettagli rimandiamo alla documentazione ufficiale. 

Non ci resta quindi che eseguire la nostra attività modificando il codice in modo da sostituire la 
corrispondente invocazione nell'attività MenuActivity e osservare il risultato: la Figura 6.6 ci mostra 
una brutta sorpresa. Da un certo punto di vista non potevamo aspettarci qualcosa di diverso in quanto 
F adapter non può sapere quale informazione del modello visualizzare all'interno della lista per cui ne 
esegue, e poi visualizza, il tostring ( ) . Questa soluzione andrebbe benissimo se il tostring ( ) 
dell'oggetto associato al modello corrispondesse esattamente a quello che si vuole mostrare, e quindi 
per oggetti relativi alle classi wrapper, string o per oggetti come il nostro in cui è stato fatto un 
override sensato del metodo toString ( ) . 
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Figura 6.6 Visualizzazione del nostro modello all'interno di una ListView. 

Nel nostro caso la cosa non funziona per cui si richiede la creazione di un layout personalizzato a 
cui segue un modo per associare ciascun elemento della UI a una particolare proprietà del modello. 

Prima di questo facciamo un passo intermedio legato alla disponibilità, nella classe ArrayAdapter, 
di un overload del costruttore che, oltre all'identificatore del layout, prevede l'identificatore della 
Textview al suo interno che dovrà visualizzare il dato. E il caso in cui volessimo aggiungere 
un'etichetta, per esempio, al layout precedente. Per mostrare questa modalità abbiamo creato il 
seguente layout nel file simpie_custom_iist_item.xmi: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android . oom/ apk/res/ android" 
android : orientation="vertical" 
android : layout_width="match_jparent " 
android : layout_height="match_parent "> 

<TextView 

android: layout_width="match_joarent " 

android: layout_height="wrap_content " 

android: text=" @string/placeholder_list_item_title" 

android : id=" @+id/list_item_title" 

android: textColor="@ color /white" 

android : background= " @ color/ dar k_grey" 
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android: layout_gravity=" center "/> 

<TextView 

android : layout_width="match_parent " 
android : layout_height="wrap_content " 
android : id= " @+id/list_item_value " 

android: layout_gravity=" center" / > 
</LinearLayout> 

Qui il layout è comunque personalizzato e contiene una Textview di cui abbiamo evidenziato Fid. 
L'activity qui è descritta dalla classe simpieCustomLocaiDataActivity e si differenzia dalla 
precedente solo per la definizione dell' ArrayAdapter, che ora viene creato attraverso questa 
istruzione: 

mAdapter = new ArrayAdapter<LocalDataModel> (this , 

R. layout . simple_custom_list_item, R. id. list_item_value, mModel) ; 

Il secondo parametro è l'identificatore del layout, mentre il terzo è l'identificatore della Textview al 
suo intemo che dovrà visualizzare il dato. Eseguendo l'applicazione il risultato sarà quello nella Figura 
6.7, dove notiamo l'utilizzo del nostro layout per ciascuna riga oltre alla visualizzazione del dato del 
modello in una parte di esso. 

Possiamo lare molto meglio e risolvere il problema della valorizzazione degli attributi del modello in 
modo opportuno. 

Layout di riga personalizzato 

Nei layout utilizzati in precedenza non potevano valorizzare più informazioni relative a imo stesso 
dato. Per farlo abbiamo bisogno di creare un layout custom che abbiamo descritto all'interno del file 
custom_iist_item.xmi e che permette una visualizzazione simile a quella nella Figura 6.8: 
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Figura 6.7 Utilizzo di un layout di riga custom. 
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Figura 6.8 II risultato del layout descritto sopra. 



<?xml version="l . 0" encoding="utf-8 " ?> 

<LinearLayout xmlns : android="http : / /schemas . android . oom/ apk/res/ android" 
android : orientation="vertical" 
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android : layout_width="match__parent " 
android : layout_height="match_parent " > 

<TextView 

android: layout_width="match_parent " 

android : layout_height="wrap_content " 

android: text=" @string/placeholder_list_item_date" 

android: id="@+id/list_item_date" 

android : textColor="@ color/ white" 

android : background=" Scolor/ dark_grey" 

android : layout_gravity=" center " /> 
<TextView 

android: layout_width="match_parent " 

android: layout_height="wrap_content " 

android: text=" @string/placeholder_love_vote" 

android : id= " @+id/list_item_love_vote " 

android: layout_gravity=" center "/> 
<TextView 

android : layout_width="match_parent " 

android: layout_height="wrap_content " 

android: text=" @string/placeholder_health_vote" 

android: id="@+id/list_item_health_vote" 

android: layout_gravity=" center " / > 
<TextView 

android: layout_width="match_parent " 

android: layout_height="wrap_content " 

android : text=" @string/placeholder_work_vote" 

android : id= " @+id/list_item_work_vote " 

android: layout_gravity=" center "/> 
<TextView 

android : layout_width="match_parent " 

android : layout_height="wrap_content " 

android : text=" @string/placeholder_luck_vote" 

android : id= " @+id/list_item_luck_vote " 

android: layout_gravity=" center" / > 
</LinearLayout> 

Qui l'adapter che andremo a realizzare dovrà in qualche modo eseguire Vinflate del layout 
precedente e quindi valorizzare i corrispondenti elementi con i dati dal modello. Qui abbiamo 
implementato la logica all'interno dell'attività descritta dalla classe customtocaiDataActivity, che 
riportiamo di seguito con evidenziate le parti di interesse: 

public class CustomLocalDataActivity extends FragmentActivity { 

private statìc final DateFormat DATE_FORMAT = new SimpleDateFormat ("E dd MMMM yyyy"); 



private ListView mLìstView; 
private ListAdapter mAdapter; 



private List<LocalDataModel> mModel = new LinkedList<LocalDataModel> ( ) ; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . simple_list_local_data) ; 
mListVìew = (ListView) findViewByld (R . id . listView) ; 
mAdapter = new BaseAdapter ( ) { @Override 

public int getCount ( ) { 

return mModel . size ( ) ; 

} 



QOverride 

public Object getltem(int position) { 
return mModel . get (position) ; 

} 



gOverride 

public long getltemld (int position) { 

LocalDataModel model = (LocalDataModel) getltem (position) ; 
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return model. id; 

} 

QOverride 

public View getView(int position, View view, ViewGroup viewGroup) { 
if (view == nuli) { 

view = getLayoutlnf later () . inf late (R. layout . custom_list_item, nuli); 

} 

final TextView dateTextView = 

(TextView) view. f indViewByld (R. id. list_item_date) ; 
final TextView loveVdteTextView = 

(TextView) view. f indViewByld (R. id. list_item_love_vote) ; 
final TextView healthVoteTextView = 

(TextView) view. f indViewByld (R. id. list_item_health_vote) ; 
final TextView workVoteTextView = 

(TextView) view. f indViewByld (R. id. list_item_work_vote) ; 
final TextView luckVoteTextView = 

(TextView) view. f indViewByld (R. id. list_item_luck_vote) ; 
final LocalDataModel itemModel = (LocalDataModel) getltem (position) ; 
dateTextView . setText (DATE_FORMAT . format (itemModel . entryDate) ) ; 
loveVoteTextView . setText (getResources () 

getString (R . string . love_value_pattern, itemModel . loveVote) ) ; 
healthVoteTextView. setText (getResources () 

. getString (R. string. health_value__pattern, itemModel . healthVote) ) ; 
workVoteTextView . setText (getResources () 

. getString (R. string. work_value_pattern, itemModel .workVote) ) ; 
luckVoteTextView . setText (getResources () 

.getString(R. string. luck_value_pattern, itemModel . luckVote) ) ; 
return view; 

} 

}; 

mListView. setAdapter (mAdapter) ; 

} 

dOverride 

protected void onStartO { 
super . onStart () ; 
// Otteniamo il modello 

final LocalVoteService . VoteTransf erOb ject result = 

LocalVoteService . sLocalVoteService . IoadVotes (0, 100) ; 
mModel . clear ( ) ; 
mModel . addAll (result .mData) ; 
mListView. setAdapter (mAdapter) ; 
} 

} 

In questo caso abbiamo abbandonato F ArrayAdapter e abbiamo deciso di implementare 
direttamente il nostro adapter estendendo la classe BaseAdapter implementando i metodi richiesti 
utilizzando i dati del modello. Vediamo come si tratti di implementazioni molto semplici che ritornano il 
numero di elementi, l'elemento data la posizione e il relativo valore di id. Il metodo più interessante è 
quello che ritorna la view da inserire nella lista. Si tratta di un'implementazione che sostanzialmente 
esegue tre operazioni: 

• nel caso di mancato riciclo, creare la view per una data posizione attraverso inflette; 

• ottenere il riferimento agli elementi della UI; 

• valorizzare gli elementi della UI con i dati del modello. 

Come abbiamo accennato, il valore del secondo parametro del metodo getview ( ) contiene il 
riferimento all'eventuale view da riutilizzare. Nel caso in cui esso sia nuli sarà responsabilità 
dell' adapter crearne un'istanza come tacciamo noi attarverso questo codice: 

if (view == nuli) { 

view = getLayoutlnf later (). inf late (R. layout . custom_list_item, nuli); 
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} 

Una volta creata o riciclata la view associata alla riga, dobbiamo ottenere i riferimenti ai diversi 
elementi per poterli poi valorizzare con i dati del modello. Questo è il motivo della serie di utilizzi del 
metodo fi ndViewByld ( ) . Infine abbiamo la valorizzazione di questi elementi attraverso i dati del 
modello. In questa fase si ha anche F opportunità di formattare tali dati in modo opportuno come 
avvenuto nel nostro caso con le date o con l'utilizzo di risorse di tipo String con parametri Nel 
codice precedente abbiamo infine evidenziato una diversa modalità di notifica della variazione dei dati, 
la quale prevede una nuova assegnazione dell' adapter alla Listview in modo da forzarne 
l'aggiornamento. Questa è un'alternativa a quella utilizzata sopra per stimolare l'update della lista. Il 
risultato di queste operazioni è mostrato nella Figura 6.9. 
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Figura 6.9 Utilizzo di un layout custom per la ListView. 



Possiamo dire di aver raggiunto il nostro obiettivo anche se, come vedremo nel prossimo 
paragrafo, possiamo fare di meglio. 

Il pattern Holder 
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Osservando il codice precedente vediamo come per ogni elemento di riga vengano eseguite le 
operazioni che permettono di ottenere il riferimento agli elementi del layout che poi si andranno a 
valorizzare. Questo avviene attraverso l'utilizzo del metodo findviewByido , che esegue una ricerca 
di un componente all'interno dell'albero che è la gerarchia delle view descritta attraverso il 
documento XML di layout. Sebbene il layout non sia eccessivamente complicato, è un'operazione 
che può essere ottimizzata anche alla luce del fatto che le view vengono riutilizzate. Serve quindi un 
meccanismo che ci permetta di eseguire queste ricerche una sola volta per ogni view creata. A tal 
proposito ci viene in aiuto la view stessa a cui è possibile associare quello che si chiama tag e che può 
essere un oggetto qualunque. Si può allora fare in modo che ciascuna view che descrive una riga della 
nostra lista porti con sé un oggetto che incapsula i riferimenti ai componenti che la stessa contiene. 
Stiamo parlando di un pattern che si chiama Hoider e che abbiamo implementato neU'activity descritta 
dalla classe HoiderCustomLocaiDataActivity, di cui descriviamo solamente rimplementazione 
dell' adapter in quanto il resto è rimasto inalterato rispetto al caso precedente, come pure il risultato 
visuale: 

mAdapter = new BaseAdapter ( ) { 

class Holder { 

TextView dateTextView; 
TextView love VoteText View; 
TextView healthVoteTextView; 
TextView workVoteTextView; 
TextView luckVoteTextView; 

} 

SOverrìde 

public int getCount ( ) { 
return mModel . size () ; 

} 

SOverride 

public Object getltem(int position) { 
return mModel . get (position) ; 

} 

SOverride 

public long getltemld (int position) { 

LocalDataModel model = (LocalDataModel) getltem (position) ; 
return model. id; 

} 

@Override 

public View getview(int position, View view, ViewGroup viewGroup) { 
Holder holder = nuli; 
if (view == nuli) { 

view = getLayoutlnf later () . inf late (R. layout . custom_list_item, nuli); 

holder = new Holder ( ) ; 

holder . dateTextView = (TextView) 

view. f indViewByld (R. id. list_item_date) ; 
holder . loveVoteTextView = (TextView) 

view. f indViewByld (R. id. list_item_love_vote) ; 
holder . healthVoteTextView = (TextView) 

view. f indViewByld (R. id. list_item_health_vote) ; 
holder . workVoteTextView = (TextView) 

view. f indViewByld (R. id. list_item_work_vote) ; 
holder . luckVoteTextView = (TextView) 

view. f indViewByld (R. id. list_item_luck_vote) ; 
view . setTag (holder) ; 
} else { 

holder = (Holder) view . get Tag () ; 

} 

final LocalDataModel itemModel = (LocalDataModel) getltem (position) ; 
holder . dateTextView 
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.setText (DATE_FORMAT . format ( itemModel . entryDate ) ) ; 

holder . loveVoteTextView 
. setText (getResources ( ) . getString (R. string. love_value_pattern, 

itemModel . loveVote ) ) ; holder . healthVoteTextView 
. setText (getResources ( ) . getString (R. string . health_value_pattern, 

itemModel . healthVote) ) ; holder . workVoteTextView 
. setText (getResources ( ) . getString (R. string . work_value_pattern, 
itemModel .workVote) ) ; 
holder . luckVoteTextView 

. setText (getResources ( ) . getString (R. string. luck_value_pattern, 

itemModel . luckVote) ) ; 
return view; 

} 

}; 

Notiamo come sia stata creata una classe interna di nome Holder, la quale non fa altro che 
memorizzare i riferimenti ai componenti visuali contenuti all'interno di una view. Tali riferimenti si 
ottengono solamente una volta in corrispondenza della creazione della view. Da notare come l'oggetto 
di tipo Holder venga poi inserito all'interno della view stessa come tag e quindi ripreso nel caso di 
riutilizzo. La parte finale del metodo corrisponde alla semplice valorizzazione degli elementi visuali a 
cui si accede attraverso il riferimento all'holder. È un pattern a volte leggermente verboso ma che può 
portare a notevoli miglioramenti delle performance, specialmente nel caso di layout di riga complicati 

Altre modalità di binding 

Nel paragrafo precedente abbiamo visto una possibile modalità per la creazione di un layout 
customper la visualizzazione di una serie di informazioni all'interno di una Listview attraverso la 
creazione di un adapter. Quella descritta dalla classe ArrayAdapter non è comunque l'unica 
implementazione disponibile; ne esistono diverse altre che possono essere utilizzate in base a quella 
che è la sorgente delle informazioni. Una di queste implementazioni si chiama simpie Adapter, che è 
molto importante in quanto utilizza uno stesso meccanismo che verrà utilizzato nella 
simpieCursorAdapter nelcaso di accesso a dati contenuti all'interno di un DB. L'aspetto negativo 
della classe SimpleAdapter è legato all'elevato numero di parametri del costruttore e alla necessità di 
utilizzare una base dati complessa che richiama comunque quella di un DB. Come dimostrazione 
dell'utilizzo di questo adapter abbiamo creato la classe simpieAdapterLocaiDataActìvity: 

public class SimpleAdapterLocalDataActivìty extends FragmentActivity { 

private static final DateFormat DATE_FORMAT = new SimpleDateFormat ( "E dd MMMM 

yyyy") ; 

private static final String [] FROM = {"date", "love", "health", "work", "luck"}; 

private static final int[] TO = {R. id. list_item_date, 

R . id . list_item_love_vote , R . id . list_item_health_vote , 
R . id . list_item_work_vote , R . id . list_item_luck_vote } ; 

private ListVìew mListView; 

private SimpleAdapter mAdapter; 

private List<Map<String, Object» mModel = new LinkedList<Map<String, Object»(); 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . simple_list_local_data) ; 
mListView = (Listview) findViewByld (R. id. listview) ; 

mAdapter = new SimpleAdapter (this, mModel, R . layout . custom_list_item, FROM, TO) ; 
mAdapter . set ViewBinder (new SimpleAdapter .ViewBinder () { 
@Override 
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public boolean setViewValue (View view, Object o, String s) { 
final TextView outputTextView = (TextView) view; 
switch (view.getld() ) { 

case R. id. list_item_date : 
Long value = (Long) o; 

outputTextView . setText (DATE_FORMAT . format (value) ) ; 
break; 

case R . id . list_item_love_vote : 

Integer loveVote = (Integer) o; 
outputTextView. setText (getResources () 
.getString(R. string. love_value_pattern, loveVote) ) ; 
break; 

case R . id . list_item_health_vote : 

Integer healthVote = (Integer) o; 
outputTextView. setText (getResources () 
. getString (R . string . health_value_pattern, healthVote) ) ; 
break; 

case R . id . list_item_work_vote : 

Integer workVote = (Integer) o; 
outputTextView. setText (getResources () 
. getString (R . string . work_value_pattern , workVote) ) ; 
break; 

case R . id . list_item_luck_vote : 

Integer luckVote = (Integer) o; 
outputTextView. setText (getResources () 
. getString (R. string. luck_value_pattern , luckVote) ) ; 
break; 

} 

return true; 

} 

}); 

mListView. setAdapter (mAdapter) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 

final LocalVoteService .VoteTransferObject result = 

LocalVoteService . sLocalVoteService . IoadVotes (0, 100 ) ; 
mModel . clear ( ) ; 

for (LocalDataModel model : result .mData) { 

final Map<String, Object> item = new HashMap<String, Object>(); 

item . put ( " date " , model . entryDate ) ; 

item . put ( " love " , model . loveVote ) ; 

item. put ( "health" , model. healthVote) ; 

item . put ( " work " , model . workVote ) ; 

item . put ( " luck " , model . luckVote ) ; 

mModel . add (item) ; 

} 

mAdapter . notif yDataSetChanged ( ) ; 
mListView. setAdapter (mAdapter) ; 

} 

} 

Il modello di cui necessita un simpieAdapter è rappresentato da una lista di Map, le quali associano 
il nome di una proprietà al corrispondente valore. Questo è il motivo per cui abbiamo dovuto eseguire 
una conversione tra il nostro LocalDataModel e la nuova struttura alfine di passarla all'adapter. La 
firma del costruttore è questa: 

mAdapter = new SimpleAdapter (this, mModel, R. layout . custom_list_item, FROM, TO) ; 

e prevede, oltre all'immancabile Context, il riferimento al modello, l'identificatore del layout e due 
array. Il primo è un array di String e contiene i nomi delle proprietà che si vogliono visualizzare. Il 
secondo array di interi contiene gli identificatori degli elementi della UI su cui i precedenti valori 
dovranno essere mappati. Anche qui il costruttore non è sufficiente, in quanto possiamo sapere su 
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quale componente mappare il valore di una proprietà del modello ma non come questo debba 
avvenire. Per questo motivo la classe simpieAdapter consente l'utilizzo di quello che si chiama 
ViewBinder, di cui abbiamo fornito un'implementazione attraverso la definizione di una classe 
anonima. Il funzionamento di questo oggetto è molto semplice e può essere descritto osservando il 
metodo da implementare: 

public boolean setViewValue (View view, Object o, String s) ; 

Esso viene invocato, per ogni riga, tante volte quante sono le proprietà da visualizzare. A ogni 
invocazione il primo parametro contiene il riferimento al componente UI che abbiamo mappato 
attraverso i precedenti array. Il secondo contiene il corrispondente valore che, nel terzo parametro, 
viene passato nella sua versione string. Il valore di ritorno indica all'adapter se il particolare dato 
debba essere gestito dal ViewBinder (valore true) oppure no (valore false). In quest'ultimo caso 
l'adapter funzionerà nella modalità standard, che non prevede la semplice assegnazione del 
tostring ( ) del dato ma che può avere anche comportamenti dipendenti dalla particolare view. 

NOTA 

Nel caso delle imageview, per esempio, il dato può essere interpretato come l'URL dell'immagine da 
visualizzare. 

Nella nostra implementazione vediamo come sia stato utilizzato l'id della view per capire di quale 
dato si trattasse per poi usarlo in modo analogo a quanto fatto nel caso precedente. Come il lettore 
potrà verificare eseguendo il corrispondente codice, il risultato non sarà cambiato, anche perché il 
layout che abbiamo usato è sempre stato lo stesso. Possiamo comunque notare come la struttura dati 
in questo caso sia molto simile a quella che si ha quando si utilizza un cursore; attraverso di esso si 
accede ai valori delle colonne di una particolare tabella di un DB. 

Selezione di un elemento della lista 

Una lista non serve solamente per la visualizzazione di un elenco di informazioni più o meno lunghe 
ma dovrà fornire un meccanismo che ne permetta la selezione. Per fare questo si utilizza Udelegation 
model registrando un listener alla lì stviewl 

mListView . setOnltemClickListener (new AdapterView . OnltemClickListener ( ) { 
SOverride 

public voìd onltemClick (AdapterView<?> adapterView, View view, int i, long 1) { 
Toast . makeText (getApplicationContext ( ) , 

"Selected position: " + i, Toast . LENGTH_SHORT) . show () ; 

} 

}) ; 

Vediamo come l'interfaccia preveda la definizione del metodo onltemClick ( ) , che notifica le 
informazioni relative alla posizione selezionata e al relativo id. La stessa interfaccia ci permette inoltre 
di ottenere il riferimento alla view selezionata e al relativo contenitore. Analogamente all'evento di clic, 
una Listview dispone di altri eventi per i quali rimandiamo alla documentazione ufficiale. 

Utilizzare la ListActivity 

Osservando le diverse applicazioni disponibili è facile comprendere come la Listview sia uno dei 
componenti più utilizzati Per questo motivo l'SDK diAndroid ci mette a disposizione una serie di 
strumenti che ci aiutano in diversi contesti semplificandone lo sviluppo. 

Nel caso in cui la Listview occupi tutto il display si può utilizzare la classe ListActivity, la quale 
dispone di improprio layout contenente già la lista. Se estendiamo questa classe invece che la classica 

262 



Activity, possiamo ottenere lo stesso risultato degli esempi precedenti senza preoccuparci della 
creazione di un layout né di ottenere il riferimento alla lì stview per assegnarvi un'implementazione di 

Adapter. Per descriverne l'utilizzo abbiamo Creato la classe SimpleAdapterLocalDataListActivity, 

che descriviamo di seguito nelle parti diverse dall'attività descritta in precedenza: 

public class SimpleAdapterLocalDataListActivity extends ListActivity { 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

mAdapter = new SimpleAdapter (this , mModel, R. layout . custom_list_item, FROM, TO) ; 
mAdapter . setViewBinder (new SimpleAdapter .ViewBinder ( ) { 

// Lo stesso di prima 

}) ; 

getListView ( ) . setAdapter (mAdapter) ; 

} 

SOverride 

protected void onStartO { 
super . onStart ( ) ; 
//Lo stesso di prima 

mAdapter . notif yDataSetChanged ( ) ; 

// Abbiamo impostato nuovamente 1' adapter per aggiornarlo 
getListView ( ) . setAdapter (mAdapter) ; 

} 

gOverride 

protected void onListltemClick (ListView 1, View v, int position, long id) { 
Toast .makeText (getApplicationContext () , "Selected position: " 
+ position, Toast . LENGTH_SHORT) . show ( ) ; 

} 

} 

Innanzitutto notiamo come ora la nostra activity estenda la classe ListActivity e non più la classe 
FragmentActivity (che comunque poteva essere anche Activity inquanto non utilizzavamo al 
momento fragment). In questo modo non dovremo più impostare un layout e neppure di ottenere un 
riferimento all'oggetto di tipo Listview, che ora otteniamo semplicemente invocando il metodo 
ereditato getListView ( ) . La creazione dell' adapter è esattamente la stessa, mentre diversa è la 
modalità digestione dell'evento. Ora infatti ereditiamo il metodo onListitemciick o , che viene 
invocato appunto in corrispondenza della selezione di un elemento della lista. 

E se avessimo la necessità di creare qualcosa di ibrido che contenga una Listview ma anche altri 
componenti, è possibile utilizzare ancora la ListActivity? La risposta è affermativa, a patto che la 
Listview all'interno del layout impostato venga associata al seguente valore di id: 

android: id=" Sandroid : id/list" 

corrispondente alla costante andrò id.R. id. list. In questo caso è possibile inoltre gestire in modo 
automatico il fatto che la lista sia vuota. Si può infatti creare una view e associare a essa il seguente 
identificatore: 

android: id=" Sandroid : id/empty" 

corrispondente alla costante android. R.id.empty. In questo modo possiamo definire la view che 
verrà visualizzata automaticamente nel caso in cui la lista fosse vuota e che sparirà non appena la lista 
disporrà di informazioni Per dimostrare il funzionamento di questa modalità abbiamo creato il 
seguente layout nel file activity_iist_iayout . xmi: 

<?xml version="l . 0" encoding="utf-8" ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/ apk/ res /android" 
xmlns : tools="http : // schemas . android . com/tools " 
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android : layout_width="match_parent " 
android : layout_height="match_parent "> 

<ListView 

android : layout_width="match_jparent " 
android: layout_height="wrap_content " 
android: id="@ android: id/list" 

android : layout_gravity=" center" 

tools : listitem=" @ layout/ custom_list_item" / > 
<TextView 

android: layout_width="wrap_content " 

android: layout_height="wrap_content " 

android: textSize="30sp" 

android : textColor="@ color/ red" 

android: layout_gravity=" center" 

android: id="@android: id/empty" 

android : text=" @string/empty_list_message"> 
</TextVìew> 
</FrameLayout> 

Abbiamo modificato Factivity precedente in modo da utilizzare il layout e visualizzare l'elenco di 
elementi solamente a seguito della selezione di un' opzione nel relativo menu. Abbiamo così creato la 
classe LocalCompleteListActivity, che non riportiamo in quanto molto simile alla precedente. 
Quando Pactivity viene avviata si ottiene il risultato nella Figura 6.10, dove viene visualizzato il 
messaggio di lista vuota. 



*J I 15: 



© UGHO 



List empty! 



264 



<7D d a 



Figura 6.10 Messaggio di lista vuota. 



Alla pressione della corrispondente voce del menu delle opzioni si potrà osservare la 
visualizzazione dei dati come nei casi analizzati e l'eliminazione del messaggio di lista vuota. 

List con item di tipo diverso 

Descrivendo l'interfaccia Adapter abbiamo visto come esso dia la possibilità di gestire un certo 
numero di tipi diversi di elementi di una lista o altra AdapterView. Come dimostrazione di questa 
feature abbiamo creato un nuovo layout che si differenzia dal primo solamente per il colore di sfondo. 
Abbiamo così creato il file custom_list_item_2 .xml. 

NOTA 

Questo poteva essere gestito in modo diverso semplicemente modificando a runtime lo sfondo di 
uno stesso layout. Vedremo comunque più avanti un utilizzo più complesso di questa importante 
funzionalità. 

Abbiamo quindi creato la classe AiternateLocaiDataActivity aggiungendo a quanto descritto da 
CustomLocalDataActivity la possibilità di alternare i colori di sfondo dei vari elementi della lista. Il 
codice relativo all'implementazione dell' adapter è questo: 

mAdapter = new BaseAdapter ( ) { 
gOverride 

public int getCountO { 
return mModel . size ( ) ; 

} 

@Override 

public Object getltem(int position) { 
return mModel . get (position) ; 

} 

gOverride 

public long getltemld (int position) { 

// Ottenere l'elemento nella posizione specificata 
LocalDataModel model = (LocalDataModel ) getltem (position) ; 
return model. id; 

} 

gOverride 

public int getViewTypeCount ( ) { 
return VIEW_TYPE_NUMBER; 

} 

gOverride 

public int getltemViewType (int position) { 
return position % 2; 

} 

@Override 

public View getview(int position, View view, ViewGroup viewGroup) { 
if (view == nuli) { 

// Dobbiamo espandere (inflate) il layout 
if (getltemViewType (position) == 0) { 

view = getLayoutlnf later () . inflate (R. layout . custom_list_item, nuli); 
} else { 

view = getLayoutlnf later () . inflate (R. layout . custom_list_item_2, nuli) ; 

} 

} 

//Lo stesso di prima 
return view; 

} 

}; 



265 



Vediamo come il nostro adapter esegua Yoverrìding delle operazioni che ci permettono di sapere 
quanti tipi di view diversi sono presenti e, per ogni posizione, a quale di questi la relativa view 
appartiene. Nella nostra implementazione abbiamo semplicemente fatto in modo che le posizioni pari 
corrispondano a un tipo e quelle dispari a un altro. Certi del fatto che le view da riutilizzare fossero 
del tipo corretto, abbiamo eseguito Y inflette del layout corrispondente al valore ritornato dal metodo 
getltemViewType ( ) . Il risultato è quello nella Figura 6.11. 
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Figura 6.11 Adapter con tipi di view diverse. 



Nelle applicazioni reali il tipo di view da utilizzare dovrà dipendere dallo stato degli elementi che le 
stesse dovranno visualizzare. Potremmo, per esempio, utilizzare un layout diverso e visualizzare dati 
differenti a seconda di quale delle categorie è quella con il voto più alto. 

ListView e fragment 

Fino a questo momento abbiamo ragionato in termini di schermate e quindi di activity creando dei 
layout con delle Listview oppure utilizzando quello associato a una List Activity. Nel Capitolo 4 
abbiamo però visto quanto i fragment siano importanti al fine di rendere la nostra applicazione più 
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aperta verso dispositivi con dimensioni grandi, come i tablet. Per questo motivo non potevano 
mancare gli strumenti per creare delle liste all'interno di un fragment. Una prima opzione, che non 
tratteremo in quanto ormai banale, prevede di associare a un fragment un layout contenente una 
Listview da gestire nel modo ormai noto. 

Una seconda opzione prevede invece l'utilizzo della classe ListFragment con un layout simile a 
quello personalizzato della lì stActivity. Anche qui si hanno le limitazioni relative agli id della lista e 
della view da visualizzare nel caso di assenza di dati. Come dimostrazione di questo utilizzo abbiamo 
riprodotto lo stesso esempio relativo alla lista vuota e all'azione di riempimento a seguito della 
selezione di un'opzione. Abbiamo riutilizzato lo stesso layout contenuto nel file 

activity_list_layout .xml e poi riadattato le classi LocalDataActivity e LocalDataFragment. 

Quest'ultima classe avrà il seguente codice: 

public class LocalDataFragment extends ListFragment { 

private static final DateFormat DATE_FORMAT = new SimpleDateFormat ( "E dd MMMM 
yyyy") ; 

private static final int VIEW_TYPE_NUMBER = 2; 
private BaseAdapter mAdapter; 

private List<LocalDataModel> mModel = new LinkedList<LocalDataModel> ( ) ; 
SOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setHasOptionsMenu (true) ; 

} 

SOverride 

public View onCreateView (Layoutlnf later inflater, VìewGroup container 
, Bundle savedlnstanceState) { 
View customLayout = inflater 

. ìnf late (R. layout . activity_list_layout , nuli) ; 
return customLayout; 

} 

SOverride 

public void onStartO { 
super . onStart ( ) ; 

// Creiamo l'adapter da assegnare al listview 
mAdapter = new BaseAdapter ( ) { 

// SAME IMPLEMENTATION 

}; 

setListAdapter (mAdapter) ; 

} 

gOverride 

public void onListltemClick (Listview 1, View v, int position, long id) { 
Toast .makeText (getActivity () , "Selected position: " + position 
, Toast . LENGTH_SHORT) . show ( ) ; 

} 

SOverride 

public void onCreateOptionsMenu (Menu menu, Menulnf later inflater) { 
inflater. inflat e (R.menu . activity_list , menu) ; 
super . onCreateOptionsMenu (menu, inflater) ; 

} 

SOverride 

public boolean onOptionsItemSelected (Menultem menultem) { 
if (menultem. getltemld ( ) == R . id . action_update_list ) { 
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// Otteniamo il modello 

final LocalVoteService . VoteTransf erOb ject result = 
LocalVoteService . sLocalVoteService . IoadVotes (0, 100) ; 
// Aggiorniamo l'adapter 
mModel . clear ( ) ; 
mModel . addAll (result .mData) ; 
mAdapter . notif yDataSetChanged ( ) ; 

} 

return super . onOptionsItemSelected (menultem) ; 

} 

} 

Innanzitutto notiamo come sia possibile associare delle opzioni alla visualizzazione di un fragment 
attraverso un meccanismo analogo a quello che vedremo nel Capitolo 7, a patto di abilitare questa 
funzionalità attraverso l'istruzione 

setHasOptionsMenu (true) ; 

che noi abbiamo messo nell'implementazione del metodo oncreate o . L'assegnazione dell' adapter 
alla Listvìew avviene invece attraverso l'istruzione 

setLìstAdapter (mAdapter) ; 

Infine notiamo la presenza del metodo onListitemciìck ( ) , che viene invocato in corrispondenza 
della selezione di un elemento della lista in modo analogo a quanto succedeva nelle specializzazioni di 

ListAcitivity. 

La classe LocaiDataActivity torna a essere quella di prima e quindi torna a estendere la classe 
FragmentActivity per la gestione dei fragment: 

public class LocalDataActìvity extends FragmentActivity { 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_single_f ragment) ; 

// Se non è già stato fatto aggiungiamo il Fragment 
if (savedlnstanceState == nuli) { 

final LocalDataFragment fragment = new LocalDataFragment ( ) ; 

getSupportFragmentManager ( ) . beginTransaction ( ) 
. add (R . id . anchor_point , fragment) .commit () ; 

} 

} 

} 

Anche il layout torna a essere quello precedente che definisce un solo punto di aggancio per il 
fragment. 

Casi d'uso frequenti 

In questo capitolo abbiamo descritto il concetto fondamentale di adapter e abbiamo realizzato degli 
esempi che ci permettano di implementare i casi più comuni di lista. In realtà abbiamo tralasciato quelli 
relativi all'accesso al DB o ai content provider a cui dedicheremo comunque parte del Capitolo 8. 
Vogliamo ora concludere con due casi, non banali, di personalizzazione di un adapter per la divisione 
delle informazioni in sezioni e per il caricamento delle informazioni in modalità lazy. Per implementare 
questa funzionalità utilizzeremo alcuni famosi pattern GoF che descriveremo nel dettaglio 
ogniqualvolta ne avremo bisogno. Nella creazione di queste funzionalità abbiamo applicato un 
principio fondamentale della programmazione ad oggetti che si chiama OCP {Open dose Principle), 
il quale dice che è sempre bene essere aperti alle estensioni ma chiusi alle modifiche. Questo significa 
che se disponiamo di alcune API e vogliamo implementare una nuova funzionalità è preferibile non 



268 



modificare quello che è già stato realizzato e che presumibilmente funziona, ma piuttosto estendere nel 
senso di aggiungere. 
NOTA 

Quando si parla di estensioni si parla di aggiunte e non di estensioni nel senso di ereditarietà. 

Quasi tutti i pattern della GoF si basano su questo principio, che nel caso specifico ci consentirà di 
creare delle sezioni a partire da adapter già esistenti e allo stesso modo applicare a essi la funzionalità 
di lazy loading. Vedremo come, attraverso il, pattern Decorator, si potranno combinare le due 
funzioni sempre nel rispetto di OCP. Iniziamo la descrizione delle nostre classi che abbiamo inserito 
all'interno del sottopackage adapters. 

La divisione in sezioni 

Come detto il nostro primo obiettivo consiste nella creazione di un adapter in grado di dividere le 
informazioni da visualizzare in sezioni secondo un particolare criterio. All'inizio di ognuna di queste 
aggregazioni vogliamo aggiungere un header che descriva la sezione che intende rappresentare. Un 
esempio è quello che si può avere in una rubrica dove i nomi e i cognomi sono raggruppati secondo le 
iniziali, oppure un insieme di date raggruppate per settimane o per mesi Vogliamo raggiungere questo 
obiettivo utilizzando i dati di un'implementazione esistente di adapter che andremo a "decorare" con 
le informazioni relative alle varie sezioni Come possiamo intuire il pattern GoF che andiamo a 
utilizzare si chiama Decorator e permette di aggiungere delle funzionalità a un oggetto senza 
modificarlo. Nel nostro caso definiremo la classe s ectionAdapterDecorator<E>, che andrà a 
decorare un oggetto, che chiameremo Adaptee, che sarà di tipo Ba seAdapter. 

NOTA 

Forse il fatto che l'oggetto da decorare sia un BaseAdapter e non un ListAdapter potrebbe sembrare una 
limitazione ma, come è possibile verificare osservando la documentazione, la maggiore parte delle 
implementazioni degli adapter estende BaseAdapter. La scelta è stata dettata dal fatto che un 
LìstAdapter non prevede necessariamente i metodi di notifica della variazione delle informazioni 
memorizzate, cosa invece implementata in un BaseAdapter attraverso i metodi notif yDataSetChanged { ) © 

notìfyDataSetlnvalidated { } . 

Ma come farà il nostro sectionAdapterDecorator<E> a suddividere la visualizzazione dei dati 
dell' Adaptee in sezioni? Per implementare questo comportamento utilizziamo gli stessi meccanismi 
utilizzati da Java per il confronto di due oggetti dello stesso tipo, i quali vengono utilizzati dalle diverse 
implementazioni degli algoritmi di ordinamento basati, appunto, sul confronto. Qualunque oggetto può 
infatti implementare l'interfaccia Comparable<T>: 
public int compareTo(T o) 

la quale dovrà ritornare un valore negativo nel caso in cui l'oggetto corrente sia minore di quello di 
tipo t conciai viene confrontato. Un valore positivo indica che l'oggetto corrente è maggiore, mentre 
un valore paria 0 ne indica l'uguaglianza. Quindi un oggetto di tipo t che implementa l'interfaccia 
comparabie<T> è un oggetto in grado di confrontarsi con i propri simili Questa prima modalità ha 
però uno svantaggio: il criterio di ordinamento è sempre lo stesso. In questo modo non è possibile 
fare in modo che uno stesso oggetto di tipo t possa essere ordinato prima secondo un criterio e 
successivamente secondo un altro criterio, almeno senza modificarne il codice che sappiamo essere, 
in onore dell'OCP, cosa vietata. In questi casi la risposta è quella di delegare il confronto tra due 
oggetti a un terzo oggetto che qui dovrà implementare l'interfaccia Comparator<T> del package 
java, ut il, e fornire implementazione delle seguenti operazioni 
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public int compare (T ol, T o2) 



public boolean equals (Ob ject obj) 

La prima dovrà confrontare i valori corrispondenti ai due parametri e ritornare un valore intero che 
segue lo stesso schema del metodo compareTo ( ) . Il secondo metodo ci porterebbe a un discorso 
troppo lungo. Per il momento diciamo che ognicomparator<±> dovrebbe anche saper riconoscere 
altri comparator<T> in grado di indicare uno stesso ordine. La cosa fondamentale è però che la 
necessità di un nuovo criterio di ordinamento si traduce nella realizzazione di una nuova 
implementazione dicomparator<±> senza che serva modificare ciò che esiste già. In ogni caso, anche 
per il nostro decorator abbiamo deciso di adottare gli stessi meccanismi. Tutti gli oggetti gestiti da un 
adaptee potranno quindi implementare un'interfaccia che abbiamo chiamato sectionabie<T> e fornire 
improprio criterio digestione delle sezioni, oppure il decorator potrà decidere di delegare i confronti 
a un particolare oggetto di tipo s ectionator<T>. In quest'ultimo caso il fatto di delegare a un 
Sectionator<T> il particolare criterio di composizione delle sezioni corrisponde all'applicazione di un 
altro pattern GoF che si chiama Strategy. Delegando tale meccanismo ad oggetti s ectionator<T> 
diversi potremo avere diverse modalità di suddivisione in sezioni. 

NOTA 

In questa fase facciamo due osservazioni. La prima è che i nomi scelti per le due interfacce non 
corrispondono a termini inglesi esistenti. La seconda riguarda invece una limitazione del nostro 
adapter, cioè quella di richiedere che l'adaptee fornisca già le proprie informazioni ordinate secondo 
il meccanismo di creazione delle sezioni. Infine, d'ora in poi utilizzeremo e come nome del 

parametro tipo per indicare che si tratta di elementi. 

La nostra interfaccia s ectionable<E> ha il seguente codice: 

public interface Sectionable<E> { 

String NOT_SECTIONABLE_ITEM = "62736947218639"; 
String getSection ( ) ; 

} 

Vediamo come essa definisca l'operazione getsection o , che ritorna il nome della corrispondente 
sezione. La costante not_sectionable_item descrive il valore che è possibile ritornare per indicare al 
nostro decorator che questa informazione di sezione dovrà essere ignorata. Un oggetto che 
implementa l'interfaccia sectionabie<T> ma che ritorna il valore dato dalla costante 
not_sectionable_item non dovrà essere considerato e verrà quindi ignorato. 

NOTA 

Per chi non è esperto di Java la sintassi precedente potrebbe portare a qualche dubbio. 
Sembrerebbe infatti che i due membri abbiamo visibilità package (o default) e che quella che 
abbiamo detto essere una costante in realtà sia una variabile. In realtà le "variabili" definite in 
un'interfaccia sono implicitamente public, static e final. Inoltre tutte le operazioni di un'interfaccia 
sono implicitamente public e abstract. 

Un'altra osservazione potrebbe riguardare il fatto che si tratti di un'interfaccia generica nonostante 
il parametro di tipo e non venga utilizzato in altri punti oltre alla definizione. Un sectionabie<string> 
ci consentirà di indicare che si tratta di un oggetto in grado di gestire string, mentre un 
sectìonabie<LocaiDataModei> ci permetterà di gestire oggetti di topo LocaiDataModei. Questo per 
indicare come comunque il tipo parametro serve in fase di compilazione per garantire la consistenza 
tra i diversi tipi di dati. 

Se ora andiamo a osservare l'interfaccia s ectionator<E> notiamo come comprenda la definizione 
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del solo metodo getSection ( ) , che questa volta ha un parametro di tipo e, come possiamo vedere 
qui; 

public interface Sectionator<E> { 
String getSection (E obj); 

} 

Un sectionator<E> è un qualunque oggetto in grado di estrarre il valore della sezione da un 
qualunque oggetto di tipo e. Anche in questo caso il valore di ritomo può corrispondere alla 
precedente costante in caso in cui l'oggetto volesse essere ignorato. 

Una volta che è stata definita la sezione di un particolare elemento, abbiamo bisogno di un 
meccanismo per astrarre la creazione della view per la sua rappresentazione. Il valore della sezione 
sarà il nome di un mese, le iniziali di un nome e così via. Serve quindi un oggetto in grado di ritornare 
la view per le sezioni, una specie di adapter delle sezioni Per questo motivo abbiamo definito anche 
la seguente interfaccia: 

public interface SectionViewFactory { 

View createSectionView (Context ctx, int position, View convertview, ViewGroup 
parent) ; 

void setValue (View sectionView, String value) ; 

} 

La responsabilità degli oggetti di questo tipo sarà quella di creare le view per la visualizzazione di 
una particolare sezione e quindi di valorizzarla con il nome di questa. La prima fase avviene attraverso 
F implementazione dell'operazione createSectionView ( ) , mentre la seconda dovrà essere 
implementata nell'operazione setvaiue ( ) . Avendo deciso di rappresentare una sezione attraverso un 
oggetto di tipo string, vediamo come non vi sia necessità di rendere questa interfaccia generica. Le 
sue diverse implementazioni saranno quelle che ci consentiranno di creare le varie intestazioni e di 
inserirle nella corretta posizione della lista. 

Eccoci finalmente alla descrizione del nostro decorator descritto dalla classe 
SectionAdapterDecorator<E>, che andiamo a illustrare nelle parti principali iniziando dai costruttori. Il 
primo di questi è il seguente: 

public SectionAdapterDecorator (Context context, BaseAdapter adaptee) { 
this . mContext = context . getApplicationContext ( ) ; 

ìf (adaptee == nuli) { 

throw new IllegalArgumentException ( "Adaptee cannot be nuli!"); 

} 

this .mAdaptee = adaptee; 
manageObservations () ; 
prepareData ( ) ; 

} 

Iniziamo subito osservando come esso abbia bisogno del riferimento all' adapter da decorare che 
abbiamo associato alla variabile d'istanza mAdaptee. Prima di questo abbiamo memorizzato il contesto 
dell'applicazione all'interno della variabile d'istanza mContext. 

NOTA 

Utilizzare il contesto dell'applicazione invece che quello delle attività è una buona tecnica per evitare 
i memory leak. 

Gli ultimi due metodi sono di fondamentale importanza. Il metodo prepareData ( ) implementa infatti 
tutta la logica del calcolo delle sezioni, che il lettore potrà consultare direttamente nel codice del 
nostro progetto. Il metodo manageObservation ( ) è altrettanto importante in quanto ci consente di 
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sistemare il meccanismo delle notifiche nel caso di aggiornamento dei dati associati. 
L'implementazione di questo metodo, e di quelli correlati, è la seguente: 

SOverride 

public void notif yDataSetChanged ( ) { 
super . notif yDataSetChanged ( ) ; 
mAdaptee . notif yDataSetChanged ( ) ; 
prepareData ( ) ; 

} 

@Override 

public void notif yDataSetlnvalidated ( ) { 
super . notif yDataSetlnvalidated ( ) ; 
mAdaptee . notif yDataSetlnvalidated ( ) ; 
prepareData ( ) ; 

} 

private void manageObservations ( ) { 

mAdaptee . registerDataSetObserver (new DataSetObserver ( ) { 

@Override 

public void onChangedO { 
super . onChanged ( ) ; 
prepareData ( ) ; 

} 

@Override 

public void onlnvalidated ( ) { 
super . onlnvalidated ( ) ; 
prepareData ( ) ; 

} 

}) ; 

} 

Vediamo come le variazioni dei dati dell' adap tee si ripercuotano in notifiche sui listener della nostra 
implementazione. 

Il secondo costruttore implica il secondo meccanismo di calcolo delle sezioni, cioè quello che 
prevede l'utilizzo dei sectionator<E>: 

public SectionAdapterDecorator (Context context, BaseAdapter adaptee, 

Sectionator<? super E> sectionator) { 

this .mContext = context . getApplicationContext () ; 
if (adaptee == nuli) { 

throw new IllegalArgumentException ( "Adaptee cannot be nuli!"); 

} 

this .mAdaptee = adaptee; 

manageObservations () ; 

this .mSectionator = sectionator; 

prepareData ( ) ; 

} 

In questo codice, oltre al salvataggio del riferimento al sectionator<E> in una variabile d'istanza, 
notiamo la presenza della sintassi <? extends e> . Questa sta a indicare che per calcolare la sezioni di 
un oggetto di tipo e non abbiamo bisogno di un sectionator<E> ma ci può andare bene anche un 
Sectìonator<F>, dove f è un super tipo di e. In pratica se abbiamo bisogno di un sectionator<cat> 
relativo ai gatti, anche UT1 Sectionator<Animal> ttl grado di determinare la sezione da un oggetto di 
tipo Animai può andare bene. Questo perché il gatto (cat) è un animale (Animai). 

Il riferimento all'oggetto di tipo sectionviewFactory avviene attraverso il corrispondente metodo 
set; si tratta infatti di un' informazione non richiesta. Nel caso in cui non venisse specificato un Factory 
per la view delle sezioni, ne creeremo imo di default, rappresentato da ima Textview. La nostra classe 
sectìonAdapterDecorator<E> dovrà essere anch' essa un adap ter e per questo motivo estende la 
classe BaseAdapter. Essa dovrà però aggiungere tutto ciò che riguarda le sezioni alle view ritornate 
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dall' adaptee. Iniziamo allora la descrizione di tutte le operazioni di cui abbiamo dovuto fare 
Yoverride, proprio per aggiungere queste nuove informazioni relative agliheader. Iniziamo dalle 
operazioni per l'abilitazione o meno delle celle: 

SOverride 

public boolean areAUItemsEnabled ( ) { 
return false; 

} 

SOverride 

public boolean isEnabled (ìnt position) { 

if (mSectionPositionLìst . contains (position) ) { 

return false; 
} else { 

int newPosition = mPositionMap . get (position) ; 
return mAdaptee . isEnabled (newPosition) ; 

} 

} 

Il metodo areAUItemsEnabled ( ) dovrebbe indicare se tutti gli elementi della nostra lista debbano 
essere abilitati oppure no. Con questo si intende la possibilità di essere selezionati all'interno della 
lista. Le view relative alle sezioni non possono essere selezionate per cui il valore di ritomo dovrà 
essere false. La seconda operazione ci fornisce invece informazioni relativamente alla singola view 
corrispondente a una data posizione. Durante l'elaborazione iniziale della lista, viene costruita la lista 
mSectionPositionList che contiene le posizioni delle sezioni. Se la posizione passata come 
parametro nel metodo isEnabled o è una di quelle memorizzate inmSectionPositionList, allora 
corrisponde a una sezione e quindi non dovrà essere selezionabile. Qui il valore di ritomo dovrà 
essere false, mentre dovrà essere true in caso contrario, cioè quello in cui la posizione non 
corrisponda a quella di una sezione. 

Il numero di elementi della nostra lista dovrà essere ora quello ritornato dall' adaptee a cui abbiamo 
aggiunto le sezioni La nostra implementazione del metodo getcount ( ) dovrà essere la seguente: 

public int getCount() { 

return mAdaptee . getCount ( ) + mSectionSet . size ( ) ; 

} 

dove mSectionSet contiene le varie intestazioni come set per motivi di performance. Una volta che 
si conoscono le posizioni che dovranno essere occupate dalle view di sezione, sarà abbastanza 
semplice implementare i metodi successivi II metodo che ha responsabilità di ritornare l'elemento che 
occupa una particolare posizione è il seguente: 

public Object getltem(int position) { 

if (mSectionPositionList . contains (position) ) { 

int sectionlndex = mSectionPositionMap . get (position) ; 

return mSectionArray [ sectionlndex] ; 
} else { 

int newPosition = mPositionMap . get (position) ; 
return mAdaptee . getltem (newPosition) ; 

} 

} 

Se la posizione è relativa a una sezione ritorniamo il corrispondente valore. In caso contrario 
ritorniamo il valore dell' adaptee nella posizione che non tiene conto delle sezioni calcolata in 
precedenza. Un ragionamento simile è poi stato implementato come segue: 

public long getltemld (int position) { 

if (mSectionPositionList . contains (position) ) { 

return -1 * position; 
} else { 

Integer newPosition = mPositionMap . get (position) ; 
if (newPosition != nuli) { 

return mAdaptee . getltemld (newPosition) ; 
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} else { 

return -1; 

} 

} 

} 

In questo caso, se il valore dell' id non ha senso perché corrispondente a una sezione, abbiamo 
ritornato il valore - 1 . Nelle altre posizioni ritorniamo il valore ottenuto dall' adaptee. 

Il nostro obiettivo è quello di inserire delle sezioni all'interno della nostra lista, le quali saranno 
rappresentate da view di tipo diverso rispetto a quello dell' adaptee. Per questo motivo abbiamo 
implementato i metodi relativi ai tipi diversi di view nel seguente modo: 

public int getViewTypeCount ( ) { 

return mAdaptee . getViewTypeCount ( ) + 1; 

} 

SOverride 

public int getltemViewType (int position) { 

if (mSectionPositionList . contains (position) ) { 

return mAdaptee . getViewTypeCount () ; 
} else { 

Integer newPosition = mPositìonMap . get (position) ; 
if (newPosition == nuli) { 

return getViewTypeCount ( ) ; 
} else { 

return mAdaptee . getltemViewType (newPosition) ; 

} 

} 

} 

Il numero di tipi di view è aumentato di 1 , a meno di non complicare il tutto prevedendo la 
possibilità di generare view diverse per sezioni diverse. Il metodo che ci indica poi a quale tipo di 
view corrisponde il dato in una particolare posizione, abbiamo utilizzato le stesse informazioni viste 
prima relative alle posizioni delle sezioni. 

Siamo finalmente giunti ai metodi responsabili della creazione delle view associate a un dato in una 
certa posizione: 

public View getview(int position, View convertview, ViewGroup parent) { 
if (mSectionPositionList . contains (position) ) { 

return getSectionView (position, convertview, parent); 
} else { 

int newPosition = mPositionMap . get (position) ; 

return mAdaptee . getview (newPosition, convertview, parent); 

} 

} 

public View getSectionView (int position, View convertview, ViewGroup parent) { 
View returnView = nuli; 
if (mSectionViewFactory != nuli) { 

returnView = mSectionViewFactory . createSectionView (mContext, 

position, convertview, 

parent) ; 

mSectionViewFactory . setValue (returnView, (String) getltem (position) ) ; 
} else { 

if (convertview == nuli) { 

AbsListView . LayoutParams lp = new AbsListView . LayoutParams ( 
AbsListView . Layout Params . MATCH_PARENT, 
AbsListView. LayoutParams .WRAP_CONTENT) ; 
returnView = new TextView (getContext ( ) ) ; 
returnView . setLayoutParams ( lp) ; 
} else { 

returnView = (TextView) convertview; 

} 

((TextView) returnView) . setText ( (String) getltem (position) ) ; 

} 

return returnView; 
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} 

In particolare, il metodo getview ( ) controlla che la view corrisponda o meno a quella di una 
sezione. In caso negativo si utilizza la view ritornata dall' adaptee. In caso positivo si delega la 
creazione della view a un altro metodo, non appartenente all'interfaccia Adapter, che verifica la 
presenza di un sectionviewFactory. Nel caso in cui fosse stata impostata, a essa delegheremo la 
creazione e valorizzazione della corrispondente view. In caso contrario possiamo notare come venga 
creata un'istanza di una Textview in cui inserire il tutto. 

I successivi due metodi sono banali e permettono di indicare se gli id sono da considerarsi stabili e 
se P adapter è vuoto. Queste informazioni vengono delegate completamente alle corrispondenti 
implementazioni dell' adapter: 

public boolean hasStablelds ( ) { 

return mAdaptee . hasStablelds () ; 

} 

public boolean isEmptyO { 

return mAdaptee . isEmpty () ; 

} 

Le ultime due operazioni permettono agli eventuali DataSetobserver di registrarsi e de- registrarsi 
per ricevere le notifiche relativamente alle variazioni dei dati Anche qui il tutto viene delegato ai 
proprietari: 

public void registerDataSetObserver (DataSetobserver observer) { 
mAdaptee . registerDataSetObserver (observer) ; 

} 

public void unregisterDataSetObserver (DataSetobserver observer) { 
mAdaptee . unregisterDataSetObserver (observer) ; 

} 

Dopo questo lungo lavoro non ci resta che verificarne il funzionamento. Per questo motivo 
abbiamo implementato la classe sectionLocaiDataFragment che si differenzia dalle precedenti per 
quella che è la creazione dell' adapter. Qui abbiamo utilizzato le seguenti righe: 

mAdapter = new BaseAdapter ( ) { 
// Lo stesso di prima 

}; 

final LayoutSectionViewFactory sectionHeaderFactory = 

new LayoutSectionViewFactory (R. layout . section_header) { 

SOverride 

public void setValue (View sectionView, String value) { 
// Otteniamo il riferimento alla Textview 
final Textview outputTextView = (Textview) 

sectionView . f indViewByld (R . id . section_header ) ; 
outputTextView . setText (value) ; 

} 

}; 

final LocalDataModelSectionator sectionator = new LocalDataModelSectionator () ; 
mSectionAdapter = new SectionAdapterDecorator<LocalDataModel> (getActivity () , 

mAdapter, sectionator) ; 
mSectionAdapter. setSectionViewFactory (sectionHeaderFactory) ; 
setListAdapter (mSectionAdapter) ; 

Dopo aver creato un adapter abbiamo creato un'istanza di un'implementazione dell'interfaccia 
SectionviewFactory attraverso l'utilizzo di un documento di layout. Abbiamo infatti creato una classe 
di utilità di nome LayoutsetionviewFactory che permette il caricamento del layout dell'header 
direttamente indicando l'identificativo della risorsa. Responsabilità delle diverse specializzazioni sarà 
anche l'assegnazione del valore associato alle sezioni; 

public abstract class LayoutSectionViewFactory implements SectionviewFactory { 
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private final int mLayoutld; 

public LayoutSectionViewFactory (int layoutld) { 
this .mLayoutld = layoutld; 

} 

SOverride 

public View createSectionView (Context ctx, int position, 

View convertView, ViewGroup parent) { 

View sectionView = nuli; 
if (convertView == nuli) { 

sectionView = Layoutlnf later . from (ctx) . inf late (mLayoutld, nuli) ; 
} else { 

sectionView = (TextView) convertView; 

} 

return sectionView; 

} 

SOverride 

public abstract void setValue (View sectionView, String value) ; 

} 

È importante notare come il layout utilizzato in questa làse per gli header sia composto dalla sola 
Textview. Una volta creato l'oggetto responsabile della renderizzazione della view relativa all'header, 
abbiamo creato un'implementazione di s ectionator<LocalDataModel> in grado di classificare un 
oggetto del tipo corrispondente al nostro modello. È un'implementazione molto semplice che utilizza 
la data per classificarla in base all'accoppiata mese-anno: 

public class LocalDataModelSectionator implements Sectionator<LocalDataModel> { 

private static final DateFormat DATE_FORMAT = new SimpleDateFormat ( "MMMM yyyy"); 
@Override 

public String getSection (LocalDataModel obj) { 
Calendar calendar = Calendar . getlnstance () ; 
calendar . setTimelnMillis (obj . entryDate) ; 
return DATE_FORMAT . format ( calendar . getTime ( ) ) ; 

} 

} 

Le ultime istruzioni ci permettono di creare il nostro decorator, assegnargli il riferimento all'oggetto 
SectionViewFactory e quindi assegnarlo alla Listview. Il risultato che si ottiene è quello nella Figura 
6.12. 
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Figura 6.12 Utilizzo del Decorator per l'aggiunta delle sezioni. 



Abbiamo così creato un piccolo framework per la personalizzazione degli header e per la 
definizione del criterio di definizione delle sezioni. Manca però ancora un ultimo passo legato alla 
gestione degli eventi, che dovrebbe tener conto della presenza delle view dedicate alle sezioni che non 
sono comunque selezionabili. Per questo motivo abbiamo definito, all'interno della classe 

SectionAdapterDecorator<E>, il Seguente metodo: 

public int getOriginalPosition (int position) { 
if (mSectionSet . contains (position) ) { 

return -1; 
} else { 

Integer originalPosition = mPositionMap . get (position) ; 
if (originalPosition != nuli) { 

return originalPosition; 
} else { 

return -1; 

} 

} 

} 

Esso ritorna, data la posizione ritornata dalla lista, il valore della posizione corrispondente 
nell'adapter originale, cioè quello che abbiamo finora chiamato adaptee. Il nostro fragment dispone 
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quindi di questo metodo: 

gOverride 

public void onListltemClick (ListView 1, View v, int position, long ìd) { 
int originalPosition = mSectionAdapter . getOriginalPosition (position) ; 

Toast .makeText (getActivìty () , "Selected position: " 

+ originalPosition, Toast . LENGTH_SHORT) . show () ; 

} 

che tiene conto della traslazione delle posizioni degli elementi a causa dell'inserimento delle view 
dedicate alle sezioni. È interessante notare come in effetti sia stato decorato l'adapter che già 
prevedeva l'utilizzo di un doppio tipo di cella. Questa è una prova di come sia stato applicato l'OCP 
in modo corretto. 

Liste con caricamento lazy 

Utilizzando lo stesso principio abbiamo poi realizzato un decorator in grado di aggiungere, nel caso 
in cui ve ne fosse bisogno, un elemento alla fine della lista, selezionando il quale si possono caricare, e 
quindi visualizzare, nuovi elementi Per realizzare questa funzionalità abbiamo creato la classe 
LazyAdapterDecorator<E>, che nonhabisogno di delegare operazioni del tipo di quelle descritte nel 
caso delle sezioni ma solamente quella di creazione della view da "appendere". Per questo motivo è 
stata realizzata la classe astratta MoreviewFactory, che consente la gestione dell'evento di selezione 
delegando alle proprie estensioni la creazione della view. Attraverso l'invocazione del metodo 
ioadNext ( ) possiamo notificare la richiesta di nuovi dati 

public abstract class MoreviewFactory { 

public interface OnMoreViewClickListener { 
void moreClicked () ; 

} 

private OnMoreViewClickListener mOnMoreViewClickListener; 

public void setOnMoreViewClickListener (final OnMoreViewClickListener 

OnMoreViewClickListener) { 
thìs . mOnMoreViewClickListener = OnMoreViewClickListener; 

} 

protected void IoadNext ( ) { 

if (mOnMoreViewClickListener != nuli) { 

mOnMoreViewClickListener . moreClicked ( ) ; 

} 

} 

public abstract View createMoreView (Context ctx, int position, 

View convertView, ViewGroup parent) ; 

} 

Nel nostro esempio abbiamo creato una realizzazione di base descritta nella classe 

ButtonMoreViewFactory, che Utilizza Itti Semplice Button: 
public class ButtonMoreViewFactory extends MoreviewFactory { 

public View createMoreView (Context ctx, int position, 

View convertView, ViewGroup parent) { 
// In questo caso la view è semplicemente Button 
Button nextButton = new Button (ctx); 

AbsListView . LayoutParams lp = new AbsListView. LayoutParams ( 

AbsLìstView. LayoutParams . MATCH_PARENT, 

AbsListView. LayoutParams . WRAP_CONTENT ) ; 
nextButton . setLayoutParams (lp) ; 
nextButton . setGravity (Gravity . CENTER) ; 
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nextButton . setText (R. string.more_button_label) ; 
nextButton . setOnClickListener (new View . OnClickListener ( ) { 
SOverride 

public void onClick (View view) { 
IoadNext ( ) ; 

} 

}) ; 

return nextButton; 

} 

} 

Il nostro decorator segue quindi lo stesso principio di quello realizzato per la suddivisione in sezioni 
anche se risulta questa volta molto più semplice. Ora la view da aggiungere alla lista, la cui creazione è 
delegata al particolare MoreviewFactory, è al più una. Lasciamo al lettore la consultazione del 
corrispondente codice e ci concentriamo sulla classe LazyLocalDataFragment descrivendone 
solamente le parti di interesse: 

@Override 

public void onStartt) { 
super . onStart () ; 
mAdapter = new BaseAdapter ( ) { 
//Lo stesso di prima 

}; 

mLazyAdapter = new LazyAdapterDecorator<LocalDataFragment> (getActivity () , mAdapter); 
mLazyAdapter . setOnMoreListener (new LazyAdapterDecorator . OnMoreListener ( ) { 
QOverride 

public void moreClicked (int currentCount) { 
f etchData ( ) ; 

} 

}); 

setListAdapter (mLazyAdapter) ; 

} 

@Override 

public void onListltemClick (ListView 1, View v, int position, long id) { 
Toast .makeText (getActivity () , "Selected position: " + position, 
Toast . LENGTH_SHORT) . show ( ) ; 
} 

private void fetchData() { 

final LocalVoteService . VoteTransferOb ject result = 
LocalVoteService . sLocalVoteService . IoadVotes (mFirst , PAGE_LENGTH) ; 
mModel . addAll (result . mData) ; 

final boolean hasMore = mModel . size () < result .mTotal; 
mLazyAdapter. setMoreEnabled (hasMore) ; 
mAdapter . notif yDataSetChanged ( ) ; 
if (hasMore) { 

mFirst += PAGE_LENGTH; 

} 

} 

Ora la logica di caricamento e aggiornamento dell' adapter è stata definita all'interno di un metodo 
di utilità privato di nome f etchData ( ) , il quale si occupa di gestire la paginazione degli elementi 
incrementando il valore della variabile mFirst. Vediamo infine come la decisione di abilitare o meno il 
pulsante di caricamento lazy a seguito della disponibilità di nuove informazioni è presa in questa classe 
e non nell' adapter stesso. Serve infatti F informazione relativa al numero totale di elementi che è 
presente nel risultato dell'invocazione del servizio. 

Il risultato di quanto ottenuto è quello nella Figura 6.13, dove notiamo la presenza del pulsante 
More per il caricamento delle informazioni successive. L'utente potrà poi notare come lo stesso 
pulsante non verrà più visualizzato nel caso in cui non vi fossero più elementi a disposizione. 
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Figura 6.13 Applicazione del LazyAdapterDecorator. 




La potenza del pattern Decorator 

Concludiamo questo lungo e faticoso capitolo con la descrizione della classe 
LazySectionLocalDataFragment che unisce le feature dei due decorator appena descritti Senza 
toccare quello che è il nostro adapter iniziale, vogliamo infatti caricare in modo lazy le informazioni 
suddivise in sezioni II codice di interesse è semplice: 

final LayoutSectionViewFactory sectionHeaderFactory = new 
LayoutSectionViewFaotory (R. layout . seotion_header ) { 

@Override 

public void setValue (Vìew sectionView, String value) { 
/ / Otteniamo il riferimento alla TextView 
final TextView outputTextView = (TextView) 
sectionView. f indViewByld (R. id. section_header ) ; 
outputTextView . setText (value) ; 

} 

}; 

final LocalDataModelSectionator sectionator = new LocalDataModelSectionator ( ) ; 
mSectionAdapter = new SectionAdapterDecorator<LocalDataModel> (getActivity ( ) , 
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mAdapter, sectionator) ; 

mSectionAdapter . setSectionViewFactory ( sectionHeaderFactory ) ; 
// Decoriamo l'adapter 

mLazyAdapter = new LazyAdapterDecorator<LocalDataFragment> (getActivity ( ) , 
mSectionAdapter) ; 

mLazyAdapter . setOnMoreListener (new LazyAdapterDecorator . OnMoreListener ( ) { 
SOverride 

public void moreClicked ( int currentCount ) { 
fetchData () ; 

} 

}) ; 

// Assegniamo gli adapter alla ListView 
setListAdapter (mLazyAdapter) ; 

In queste righe abbiamo sostanzialmente eseguito alcune operazioni che dimostrano l'utilità del 
pattern Decoratori 

• è stata creata un'istanza di LayoutsectionviewFactory per la visualizzazione delle sezioni; 

• è stato creato il LocaiDataModeisectionator per il criterio di definizione delle sezioni; 

• è stata creata l'istanza di sectionAdapterDecorator a partire dall'adapter iniziale; 

• è stato creato il LazyAdapterDecorator a partire dal precedente decorator; 

• è stato assegnato questo ultimo adapter alla lista. 

Il risultato sarà quello nella Figura 6.14. 
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Figura 6.14 Utilizzo combinato dei due decorator. 



Conclusioni 

In questo capitolo abbiamo visto alcuni dei componenti fondamentali di ogni applicazione Android, 
cioè le ListView. Abbiamo introdotto e approfondito il concetto di adapter esaminandone le principali 
implementazioni. Nonostante il grande lavoro, l'argomento non è comunque concluso. Vedremo, nel 
capitolo dedicato all'accesso al DB, quali siano gli adapter che la piattaforma mette già a disposizione 
e come eventualmente estenderli allo stesso modo di quanto fatto per la gestione delle sezioni e del 
caricamento lazy delle informazioni 
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Capitolo 7 



ActionBar e menu 



In questo capitolo ci occuperemo di un componente molto importante di tutte le applicazioni 
Androidi si chiama ActionBar e permette l'accesso veloce alle funzionalità dell'applicazione, oltre a 
contenere gli elementi che ne caratterizzano il brand. Nella prima parte vedremo come gestire e 
personalizzare F ActionBar, mentre nella seconda parte cercheremo di utilizzare questo componente 
nella nostra applicazione, che dovrà però supportare anche le versioni della piattaforma precedenti la 
3.0. Vedremo quindi velocemente come installare e utilizzare ilframework ActionBar Sherlock 
(http://actionbarsheriock.com/), il quale, non senza qualche difficoltà, ci consentirà comunque di 
gestire anche le versioni precedenti 

L ActionBar 

La piattaforma Android si è sicuramente evoluta moltissimo nelle diverse versioni che si sono 
succedute in questi pochi anni di vita. Un componente che ha caratterizzato le nuove versioni è quello 
che si chiama ActionBar ; sostanzialmente è stata introdotta per permettere il posizionamento del 
brand dell'applicazione oltre che per dare indicazioni sullo stato della navigazione consentendo un 
accesso alle sue funzionalità più importanti e dirette che necessitano di essere trovate in modo 
semplice e soprattutto veloce. È bene sottolineare come l' ActionBar non venga sempre inserita nelle 
applicazioni Android. Essa viene aggiunta nel caso in cui l'applicazione abbia come API Level minimo 
o di riferimento quello relativo alla versione 3.0 (API Level 11) e utilizzi il tema di nome Theme.Hoio o 
sue declinazioni Nel caso in cui non volessimo l' ActionBar, avremmo due possibilità. La prima 
consiste nella definizione di un tema personalizzato: 

<activity android: theme=" @ android: style/Theme . Ho lo . NoAct ionBar " / > 

mentre il secondo consiste nell'ottenere un riferimento all' ActionBar per poi invocarne il metodo 

hide () : 

ActionBar actionBar =getActionBar ( ) ; 
act ionBar . hide ( ) ; 

L'ActionBar è un componente che viene inserito all'interno della gerarchia delle view ma senza 
sovrapporsi a esse. Nel caso in cui non si volesse sottrarre spazio al layout dell' activity, si può 
comunque utilizzare il seguente attributo che permette di ottenere un' Act ionBar che, quando 
visualizzata, si sovrappone al layout dell'attività senza portarle via spazio ma nascondendola in parte: 

android: windowActionBarOverlay 
NOTA 

A tale proposito è bene sottolineare come nel caso di ActionBar disabilitata, il valore di ritorno del 

metOdO getActioriBarO Sarà nuli. 

A dimostrazione di quanto detto e di come si possa gestire la visualizzazione dell' ActionBar, 
abbiamo realizzato due semplici applicazioni descritte dai progetti showActi onBarTest e 
Ove rlayAct ionBar Test. In realtà sono molto simili e si differenziano solamente per l'utilizzo 
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dell'attributo windowActionBarOveriay nella personalizzazione del tema dell'applicazione nel 
corrispondente file styies .xml delle risorse. Le applicazioni non tanno altro che ottenere un 
riferimento all'ActionBar invocando poi i metodi show ( ) e hide ( ) '. 
public class MaìnActivity extends Activity { 

SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activìty_main) ; 

} 

public void showActionBar (View button) { 
getActionBar () .show() ; 

} 

public void hideActionBar (View button) { 
getActionBar () . hide() ; 

} 

@Override 

public boolean onCreateOptionsMenu (Menu menu) { 
getMenuInf later ( ) . inf late (R. menu .main, menu) ; 
return true; 




Fino a qui non c'è nulla di particolare se non vedere come sia possibile inserire delle opzioni 
all'interno diun'ActionBar e come queste siano compatibili con le versioni precedenti della 
piattaforma. Si tratta infatti di una feature che non viene gestita in modo automatico attraverso 
l'utilizzo della Compatibility Library. Qui i dispositivi visualizzano semplicemente in modo diverso 
quelle che sono le voci di due menu distinti classificabili in: 

• menu delle opzioni; 

• menu contestuali 

Li descriveremo in modo piuttosto dettagliato vista la loro importanza. 

ActionBar e menu delle opzioni 

In generale una particolare schermata dall'applicazione consente la visualizzazione di un insieme di 
informazioni relative a una qualche entità. Pensiamo per esempio alle informazioni relative a un 
contatto che comprendono il nome, il numero di telefono e così via. Un altro esempio è quello di una 
schermata che visualizza un elenco di contatti In ciascuna di queste schermate descritte da altrettante 
activity possiamo eseguire una serie di operazioni Per esempio, possiamo editare il particolare 
contatto oppure inserirne imo nuovo. Si tratta quindi di azioni che inseriremo all'interno di un menu 
delle opzioni che viene visualizzato selezionando il corrispondente pulsante, virtuale o meno, di cui 
tutti i dispositivi sono dotati Dalla versione 3.0 della piattaforma, queste opzioni possono essere 
invece visualizzate come azioni dell' ActionBar semplicemente attraverso una opportuna 
configurazione in un file delle risorse di tipo menu. In questa occasione non descriveremo ogni 
possibile attributo di questo tipo di risorse, il quale può essere consultato nella documentazione 

ufficiale (http: //developer .android. com/guide/topics/ui/menus .html), ma Solo a quello di nome 

android: showAsAction, che può avere un valore tra i seguenti: 

• always; 

• never^ 
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• withText; 

• ifRoomj 

• collapseActionView. 

libro significato è piuttosto intuitivo. Per descriverli abbiamo realizzato l'esempio descritto dal 
progetto optionMenuTest, che definisce la seguente risorsa di tipo menu: 

<menu xmlns : android="http : / / schemas . android . com/apk/ res/android" > 
<item 

android: id=" @+id/menul " 
android: orderInCategory=" 100 " 
android: showAsAction="always" 
android: title=" @st ring/ opt ioni "/> 
<item 

android : id=" @+id/menu2 " 
android: orderInCategory="100" 
android: showAsAction="always" 
android: title=" @st ring/ opt ion2 "/> 
<item 

android: id="@+id/menu3" 
android: orderInCategory="100" 
android: showAsAction=" if Room" 
android: title=" @st ring/ opt ion3 "/> 
<item 

android : id=" @+id/menu4 " 
android: orderInCategory="100" 
android: showAsAction=" if Room" 
android: title=" @st ring/ opt ion4 "/> 
<item 

android : id=" @+id/menu5 " 
android: orderInCategory="100" 
android: showAsAction="never " 
android: title=" @st ring/ opt ion5 "/> 
<item 

android: id=" @+id/ actìon_settìngs " 

android: orderInCategory="100" 

android: showAsAction="never " 

android: title=" @st ring/ action_settings "/> 

</menu> 

Le prime due voci hanno un valore pari a aiway s che ci permette di richiedere che esse vengano 
sempre e comunque visualizzate nefl'ActionBar. Per le successive due opzioni abbiamo utilizzato il 
valore ìf Room, che ci consente di richiedere al sistema l'aggiunta di tali opzioni solamente se c'è 
abbastanza spazio. Infine, le ultime due non verranno mai inserite nell'ActionBar per cui abbiamo 
utilizzato il valore never. Le linee guida di Android prevedono infatti che opzioni come le info o la 
visualizzazione dell'help non debbano malessere inserite come azioni dell' ActionBar. Per 
completezza diciamo che il valore wìthText ci permette di richiedere la visualizzazione dell'etichetta 
anche nel caso in cui fosse associata un'immagine che è sempre la priorità. Il valore 
collapseActionView indica qualcosa di più complesso, che vedremo successivamente e che riguarda 
l'utilizzo di particolari view e layout per azioni personalizzate. Eseguendo l'applicazione otteniamo 
qanto mostrato nella Figura 7.1, dove vediamo visualizzate solo le prime due azioni, mentre le altre 
sono delegate a quello che si chiama menu in overlay e che si ottiene selezionando itre puntini 
incolonnati sulla destra (Figura 7.2). 



285 



f 00:28 




Hello world! 



Figura 7.1 Visualizzazione delle opzioni nell'ActionBar. 

Per verificare il iùnzionaniento di questi attributi suggeriamo al lettore di ruotare il dispositivo; 
avendo più spazio a disposizione, vengono visualizzate anche le azioni da noi indicate come opzionali 
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Figura 7.2 Visualizzazione del menu in overlay. 

Queste opzioni vengono create all'interno del seguente metodo che il nostro IDE implementa 
automaticamente in corrispondenza della realizzazione di un nuovo progetto: 

HOverrìde 

public boolean onCreateOptionsMenu (Menu menu) { 
getMenuInf later ( ) . inf late (R. menu .main, menu) ; 
return true; 

} 

È importante notare come si tratti di un metodo che viene invocato una volta sola ma in momenti 
diversi a seconda che debba essere visualizzata l'ActionBar oppure no. Nel secondo caso, la 
creazione delle opzioni avviene solamente in corrispondenza della loro prima visualizzazione 
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attraverso il corrispondente pulsante. 
NOTA 

Nel caso dell' ActionBar è owio che debba essere invocata subito per poter visualizzare le 
corrispondenti azioni. 

Come fare allora qualora alcune di queste dovessero essere modificate a seconda della situazione 
o dello stato dell'applicazione? In questo caso il sistema invoca, questa volta a ogni visualizzazione, il 
metodo: 

public boolean onPrepareOptionsMenu (Menu menu) 

all'interno del quale ci preoccuperemo di visualizzare o nascondere le opportune voci di menu. Nel 
caso dell' ActionBar questo metodo non viene comunque invocato, per cui si richiede un'operazione 
di invalidazione che possa portare a una nuova invocazione del metodo onCreateOptionsMenu ( ) . Per 
questo motivo è stato definito il seguente metodo: 

public void invalidateOptionsMenu () 

il quale ha come conseguenza una nuova creazione delle voci di menu o dell' ActionBar. Non ci 
resta che intercettare la selezione di una voce, e questo avviene attraverso il seguente metodo di 
callback: 

public boolean onOptionsItemSelected (Menultem item) 

il quale ha come parametro il riferimento all'oggetto di menu selezionato. 

Un aspetto molto importante oltre che interessante riguarda come gli eventuali fragment possono 
interagire con il sistema di composizione delle voci di menu e poi dell'eventuale ActionBar. Il tutto è 
molto semplice in quanto anche i fragment dispongono esattamente degli stessi metodi per la 
creazione delle voci di menu, per la loro eventuale successiva modifica e per la gestione della 
selezione. Sono voci di menu che vengono abilitate a seguito della visualizzazione del fragment 
associato. Le osservazioni importanti sono due. La prima è che si tratta di una feature da abilitare 
attraverso il seguente metodo: 

public void setHasOptionsMenu (boolean hasMenu) 

passando il valore true come parametro. La seconda riguarda l'ordine con cui i metodi 
onoptionsitemseiected o sono invocati suU'activity e sui fragment. Il funzionamento corrente 
prevede che prima venga invocato il metodo suU'activity e quindi sui fragment. L'evento si propagherà 
tra questi metodi fino a che uno di essi non ritorna il valore true, che indica che l'evento stesso è 
stato consumato e non necessita di ulteriori elaborazioni. 

ActionBar e menu contestuale 

Supponiamo ora di avere, come nel caso precedente, ima schermata con un elenco di contatti che 
vogliamo avere la possibilità di cancellare. Le linee guida di Google, prevedono che l'utente selezioni 
la voce da eliminare con un evento di long click che porterà alla visualizzazione di un menu che questa 
volta è specifico di un particolare elemento, in questo caso della lista. Si parla di menu contestuale, 
ovvero di un insieme di opzioni che descrivono azioni che possono essere eseguite su uno o più 
oggetti In Android queste opzioni si integrano molto bene con componenti associati ad adapter come 
le Listview o le Gridview. I menu contestuali sono di due tipi; 

• Floating Context Menu; 

• Contextual Action Mode. 

Il primo non è altro che un menu che compare all'interno di una finestra di dialogo al centro del 
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display. Il secondo consiste in una vera e propria personalizzazione dell' ActionBar per la 
visualizzazione di un insieme di operazioni da eseguire su uno o più elementi selezionati Descriviamo 
queste due modalità attraverso degli esempi II primo si chiama FloatingContextMenuTest, che 
sfruttiamo anche per verificare la relazione tra fragment e activity nella selezione di una voce di menu. 
NOTA 

Questa volta lo faremo su un menu contestuale ma vedremo che la logica è esattamente la stessa 
descritta per il menu delle opzioni. 

In questo esempio l'attività è molto semplice e non tà altro che aggiungere il fragment con una lista 
di opzioni descritta dalla classe My List Fragment. Nel nostro esempio abbiamo semplicemente inserito 
il metodo 

@Override 

public boolean onContextltemSelected (Menultem itera) { 

Log. i (TAG_LOG, "In Activity selected item: " + item. getTitle ( ) ) ; 
return super . onContextltemSelected (item) ; 

} 

per verificarne l'invocazione a seguito di una selezione nel menu contestuale che questa volta è 
definito all'interno di un fragment: 

public class MyListFragment extends ListFragment { 

private static final String TAG_LOG = MyListFragment . class . getName () ; 

private static final int ARRAY_S I ZE = 100; 

private Stringi] mModel; 

private ArrayAdapter<String> mAdapter; 

SOverride 

public void onActivityCreated (Bundle savedlnstanceState) { 
super . onActivityCreated ( savedlnstanceState) ; 
mModel = new String [ARRAY_SIZE] ; 
for (int i = 0 ; i < mModel . length; i++) { 
mModel [i] = "Item "+ i; 

> 

mAdapter = new ArrayAdapter<String> (getActivity ( ) , android . R. layout . simple_list_ 
item_l, mModel); 
setListAdapter (mAdapter) ; 
registerForContextMenu (getListView () ) ; 

} 

SOverride 

public void onCreateContextMenu (ContextMenu menu, View v, ContextMenuInf o menulnfo) 

{ 

Menulnflater menulnflater = new Menulnflater (getActivity ()) ; 

menu In f later . in fiat e (R .menu . ma in, menu) ; 

Log. i (TAG_LOG, "In Fragment onCreateContextMenu "); 

super . onCreateContextMenu (menu, v, menulnfo); 

} 

SOverride 

public boolean onContextltemSelected (Menultem item) { 

Log. i (TAG_LOG, "In Fragment selected item: " + item. getTitle ()) ; 
return super . onContextltemSelected (item) ; 

} 

} 

Nel codice precedente abbiamo evidenziato l'invocazione del metodo 

public void registerForContextMenu (View view) 

che consente di registrare una qualunque view, nel nostro caso una Listview, nella gestione del 
menu contestuale. La gestione è esattamente la stessa del menu delle opzioni solamente che ora i 
metodi da implementare hanno un nome leggermente diverso. La creazione del menu contestuale, che 
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questa volta avviene a ogni sua visualizzazione, dovrà essere implementata nel metodo 

public void onCreateContextMenu (ContextMenu menu, View v, ContextMenuInf o menulnfo) 

mentre in corrispondenza di una selezione si ha l'invocazione del metodo 

public boolean onContextltemSelected (Menultem itera) 

Il risultato sarà quello nella Figura 7.3. 
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Figura 7.3 Visualizzazione di un menu contestuale. 

Un'ultima osservazione riguarda l'ordine delle invocazioni del metodo di selezione. Lasciamo al 
lettore la verifica di come effettivamente venga invocato prima il metodo nell'attività e quindi il 
corrispondente nelfragment. Se poi il valore di ritorno dal metodo onContextltemSelected ( ) 
nell'activity è true, il metodo nel fragment non verrà per nulla invocato. 

La seconda modalità con cui è possibile contestualizzare un menu prende il nome di Contextual 
Action Mode e rappresenta un modo per personalizzare le opzioni dell' ActionBar a seguito della 
selezione di uno o più elementi. E una feature disponibile alla versione 11 dell' API Levelche viene 
implementata attraverso la definizione della classe astratta ActionMode. In sintesi, la procedura per 
utilizzare questa funzionalità è la seguente. 
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1 . Si crea un' implementazione dell'interfaccia ActionModei.caiiback. 

2. Si usa tale implementazione come parametro del metodo startActionMode ( ) . 

Ecco che la nuova opzione viene automaticamente disabilitata quando si preme il relativo pulsante 
Done in alto a sinistra oppure si preme il pulsante Back. Anche qui abbiamo realizzato un esempio dal 
progetto di nome ActionModeTest; la sua logica è tutta all'interno del seguente metodo, che viene 
invocato a seguito della pressione di un pulsante che abbiamo inserito nel layout principale: 

public void startActionMode ( final View button) { 
if (mActionMode != nuli) { 

// Non vogliamo che sia creato più volte 
return; 

} 

mActionMode = startActionMode (new Callback() { 
QOverride 

public boolean onCreateActionMode (ActionMode mode, Menu menu) 
Menulnf later inf later = mode . getMenuInf later ( ) ; 
inflater . inf late (R. menu . action_mode_menu, menu) ; 
return true; 

} 

QOverride 

public boolean onPrepareActionMode (ActionMode mode, Menu menu) 
return false; 

} 

gOverride 

public void onDestroyActionMode (ActionMode mode) { 
mActionMode = nuli; 

} 

QOverride 

public boolean onActionltemClicked (ActionMode mode, Menultem item) { 
CharSequence selectedTitle = item.getTitle () ; 
if (TextUtils . isEmpty (selectedTitle) ) { 
selectedTitle = "Unknown"; 

} 

Toast . makeText (getApplicationContext () , 
selectedTitle. toString() , 
Toast . LENGTH_SHORT) . show ( ) ; 
return false; 

} 

}); 

} 

Come possiamo notare, l' ActionMode viene attivato attraverso l'invocazione del metodo 
startActionMode() passando un'implementazione diActionModei.caiiback, che sostanzialmente 
indica quelle che sono le operazioni disponibili e che cosa fare quando una di queste viene 
selezionata. Vediamo come la gestione degli elementi selezionati sia qualcosa che è di responsabilità 
della particolare applicazione. Ecco che selezionando il pulsante che simula l'evento di attivazione 
otteniamo un'ActionBar come nella Figura 7.4. 
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Figura 7.4 Attivazione di un ActionMode. 

Nel caso diListview e Gridview (o comunque specializzazioni di AbsListview) è possibile 
eseguire delle azioni in batch su più elementi, per esempio la cancellazione degli item selezionati da 
una lista. Anche qui i passi sono due. 

1 . Impostare la modalità di selezione associata alla costante choice_mode_multiple_modal 
attraverso il metodo setchoiceMode o ; 

2. Registrare un AbsListview. MuitichoiceModeiListener attraverso il metodo 
setMuitichoiceModeiListener o . Esso non è altro che una specializzazione dell'interfaccia 
ActionMode. cai ìback che permette di gestire selezioni multiple. 

Anche in questo caso abbiamo realizzato un esempio descritto dal progetto BatchActionModeTest, 
che sostanzialmente implementa le due azioni precedenti, come possiamo vedere nel seguente codice: 

public class MaìnActivity extends ListActivìty { 

private static final String LOG_TAG = MainActivìty . class . getName () ; 
private ArrayAdapter<String> mAdapter; 
private Set<Integer> mSelectedSet ; 

@Override 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
mSelectedSet = new HashSet<Integer> ( ) ; 

getListView ( ) . setchoiceMode (ListView.CHOICE_MODE_MULTIPLE_MODAL) ; 
getListView ( ) . setMultiChoiceModeListener ( 



new MultiChoiceModeListener ( ) { 
QOverride 

public boolean onCreateActionMode (ActionMode mode, Menu menu) 
Menulnf later inflater = mode . getMenuInf later ( ) ; 
inflater . inf late (R. menu . action_mode_menu, menu) ; 
return true; 



} 



QOverride 

public boolean onPrepareActionMode (ActionMode mode, Menu menu) 
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return false; 

} 



@Override 

public void onDestroyActionMode (ActionMode mode) { 
} 

@Override 

public boolean onActionltemClicked (ActionMode mode, Menultem item) { 
CharSequence selectedTitle = item. getTitle () ; 

Log . i (LOG_TAG, "onActionltemClicked " + selectedTitle + " on " + 
mSelectedSet) ; 
return false; 

} 

@Override 

public void onltemCheckedStateChanged (ActionMode mode, 
int position, long id, boolean checked) { 
String selectedltem = (String) 

getListAdapter ( ) . getltem (position) ; 
if (checked) { 

mSelectedSet . add (position) ; 
} else { 

mSelectedSet . remove (position) ; 

} 

} 

}); 

String [] mockData = new String[100]; 
for (int i = 0; i < mockData . length; i++) { 
mockData [i] = "Mock Data #"+i; 

} 

mAdapter = new ArrayAdapter<String> (this , 

android . R . layout . simple_list_item_multiple_choice, mockData) ; 
setListAdapter (mAdapter) ; 

} 

public boolean onCreateOptionsMenu (Menu menu) { 
getMenuInf later ( ) . inf late (R. menu .main, menu) ; 
return true; 

} 

} 

Possiamo verificare come l'attivazione del batch mode avvenga attraverso un long click su imo 
degli elementi e come questo stato sparisca nel momento in cui si deselezionino tutte le opzioni 
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Figura 7.5 Implementazione del BatchActionMode. 



Realizzazione di un menu popup 

Per completezza vediamo velocemente come si implementa una tipologia di menu simile a quella 
contestuale che assume la forma di un menu fluttuante che può essere attivato a seguito di un 
qualunque evento. In questo caso non ci sono metodi di callback se non la creazione di un'istanza 
della classe PopupMenu, anch'essa introdotta nella versione 11 delle API. Il processo di creazione di 
un menu di questo tipo è molto semplice ed è stato implementato nell'esempio descritto dal progetto 
di nome PopupTest, di cui riportiamo il codice di interesse che abbiamo inserito all'interno del nostro 
metodo showPopup 0 , che verrà invocato a seguito della selezione di impulsante: 

public void showPopup (View button) { 

PopupMenu popup = new PopupMenu (this, button); 

popup . setOnMenuItemClickListener (new OnMenuItemClickListener ( ) { 
SOverride 

public boolean onMenuItemClick (Menultem item) { 

Log.i (LOG_TAG, "Selected " + item . getTìt le ( ) ) ; 
Toast .makeText (getApplicationContext ( ) , 
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"Selected " + item. getTitle ( ) , 
Toast . LENGTH_SHORT ) . show ( ) ; 
return false; 

} 

}) ; 

Menulnflater inflater = popup . getMenuInf later () ; 

inf later . inf late (R . menu . popup_menu, popup . getMenu ( ) ) ; 

popup . show ( ) ; 

} 

Innanzitutto notiamo come l'istanza della classe PopupMenu sia associata, oltre che all'immancabile 
Context, a una particolare view che ne determina, per esempio, la posizione. Le diverse opzioni 
possono essere iniettate attraverso la solita operazione di inflate attraverso unMenuinf later. Infine 
visualizziamo il PopupMenu invocando il metodo show ( ) . Dovremo eseguire una qualche operazione in 
risposta alla voce selezionata. A tale scopo esiste l'interfaccia OnMenuItemClickLis tener, che 
abbiamo implementato per la visualizzazione di un messaggio di Toast. Il risultato che si ottiene 
selezionando il pulsante è quello nella Figura 7.6. 

Concludiamo osservando come, dalla versione 14 delle API, sia disponibile anche un'interfaccia 
per la notifica della chiusura del suddetto menu come conseguenza, per esempio, di un evento di 
touch fuori dalla sua estensione. Qui il codice che avevamo commentato è il seguente: 

popup . setOnDismissListener (new OnDismissListener ( ) { 
@Override 

public void onDismiss (PopupMenu menu) { 
// TODO per dismiss 

} 

}) ; 

Il cui significato ora è più chiaro. 
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Figura 7.6 Visualizzazione di un menu popup. 

ActionBar e navigazione 

Nella parte introduttiva di questo capitolo, abbiamo accennato a come una delle principali 
iùnzionalità dell' ActionBar sia quella di supporto alla navigazione. Questo significa che l'utente 
dovrebbe avere, in ogni momento, una chiara percezione di qual è la schermata corrente 
dell'applicazione e quali siano le corrispondenti operazioni possibili Sappiamo che 1' ActionBar 
contiene anche l'icona dell'applicazione nella sua parte sinistra che è stata resa attiva, cioè 
selezionabile come fosse una qualunque azione di menu. Le API permettono di associare a questa 
particolare azione il ritorno aMHome oppure quella che si chiama navigation up. Intanto diciamo 
subito che, essendo di fatto un'azione, anche la selezione dell'icona provocherà l'invocazione del 
metodo dicallback onoptionsitemseiectedo a cui verrà passato un Menultem associato alla 
costante android.R.id.home. Siha di fatto una voce di menu in più, la quale dovrà comunque essere 
attivata passando un valore true come parametro del metodo 

public void setHomeButtonEnabled (boolean enabled) 
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A tal proposito è bene tare due osservazioni La prima è che il ritorno alla Home non è automatico 
ma va implementato come risposta della selezione dell'azione di Home. Quella che il sistema ci mette 
a disposizione è solamente una particolare renderizzazione dell'icona. 

NOTA 

Per impedire che si creino diverse istanze dell'attività di Home che vanno ad alimentare lo stack 
associato al corrispondente task, è bene utilizzare il flag FLAG_ACTIVITY_CLEAR_TOP. Esso consente di 
tornare all'istanza di Home di partenza eliminando tutte le attività intermedie. Si rimanda all'indirizzo 

http : / /developer . android. com/ guide /component s/tasks-and-back-stack .html. 

La seconda opzione è quella che si attiva passando il valore true come parametro del metodo 

public void setDisplayHomeAsUpEnabled (boolean showHomeAsUp. Anche qui SÌ ha l'invocazione 
del metodo onOptionsItemSelected ( ) , che dovrà implementare una logica che descriviamo con un 
semplice esempio. Supponiamo di andare dall'attività Al dell'applicazione A all'attività A2 della 
stessa per poi andare a una schermata Bl dell'applicazione B. Nel caso di attivazione dell'opzione 
navigation up, la pressione dell'azione associata all'icona dovrebbe portare la navigazione a una 
nuova attività dell'applicazione B. (Si tratta di un pattern di navigazione che si può approfondire a 
questo indirizzo della documentazione ufficiale 

http : //developer . android . com/design/patterns /navigation . html.) 

Il risultato di questa impostazione sarà quello nella Figura 7.7: notiamo la freccia a sinistra 
dell'icona. 
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Figura 7.7 Visualizzazione dell'opzione di navigation up. 



Realizzazione di ActionView personalizzate 

Talvolta occorre inserire nell'ActìonBar delle funzionalità più complesse della selezione di un 
pulsante. Una classica opzione di questo tipo è quella che permette, per esempio, di eseguire una 
ricerca che contiene un campo di input e un pulsante per l'avvio della ricerca stessa. Un altro esempio 
potrebbe essere quello della visualizzazione di uno spinner per la selezione di una particolare vista 
dell'attività o insieme di fragment correnti In questo caso si utilizzeranno alcuni attributi, nella 
definizione dei menu, che avevamo trascurato in precedenza. Come dimostrazione della realizzazione 
di un' Actionvìew abbiamo creato il progetto spinnerActionvìewTest, il quale consente appunto la 
visualizzazione di un menu a tendina (spinner) per la selezione di un qualche valore definito al suo 
intemo. Il primo passo consiste nella definizione dell' ActionView nella risorsa di tipo menu, che nel 
nostro caso è la seguente: 

<menu xmlns : android="http : / /schemas . android. com/ apk/ res/ android" > 
<item 

android: ìd="@+id/ actìon_settings" 

android: orderInCategory="100" 

android: showAsAction="never " 

android : title=" @strìng/action_settings "/> 
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<item 

android : id=" @+id/menu_spinner " 

androidi actionLayout="@layout/spinner_action_view" 
android : icon=" @android : drawable/arrow_down_f loat " 
android : showAsAction= " if Room | collapseActionView" 

android : title=" Sstring/ spinner_action_label" /> 

</menu> 

Oltre alla classica voce Settings, abbiamo creato un menu associato all'identificatore 
R . id . menu_spinner, che contiene uno spinner definito all'interno di un documento di layout descritto 
dal file spinne r_action_view nella relativa cartella. Questo layout è stato impostato utilizzando 
l'attributo android : actionLayout. E un layout molto semplice che definisce appunto uno spinner che 
contiene una serie di valori definiti in una risorsa di tipo array associata alla costante 

R . array . spinner_optionsI 

<Spinner xmlns : android="http : / / schemas . android. com/ apk/ res/android" 

xmlns :tools="http: // schemas . android . com/tools" 

android : id= " @+id/ menu_spinner " 

android: layout_width="match__parent " 

android: layout_height="wrap_content " 

android: entries="@array/ spinner_options" > 
</ Spinner> 

Tornando al nostro documento di menu, vediamo come i valori dell'attributo showAsAction siamo 
ifRoom e collapseActionView. Il primo è ormai noto e permette di indicare che la voce di menu 
dovrebbe essere visualizzata solamente e c'è abbastanza spazio. Il secondo valore indica invece che 
normalmente il layout associato non deve essere visualizzato subito ma solamente come conseguenza 
della selezione della corrispondente azione. In pratica si vuole che l'ActionView personalizzata non 
venga visualizzata se non quando richiesto. Per chiarire meglio, il lettore potrà eseguire l'applicazione, 
ottenendo inizialmente un'ActionBar come nella Figura 7.8. 




Hello world! 



Figura 7.8 L'ActionView inizialmente non è espansa. 

Notiamo come non venga visualizzato il layout con lo spinner ma solamente la sua immagine (nel 
nostro caso una piccola freccia verso il basso) che indica la presenza della corrispondente azione. Se 
la selezioniamo vediamo come 1' ActionBar diventi quella nella Figura 7.9, dove l'icona 
dell'applicazione acquisisce l'immagine caratteristica di un navigation up come già descritto; il titolo 
sparisce e compare il layout che le abbiamo associato nella risorsa di tipo menu, ovvero lo spinner. 
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Figura 7.9 Visualizzazione del layout associato all'opzione. 

Attraverso lo spinner possiamo selezionare uno dei valori e quindi gestire il corrispondente evento. 
Questo comportamento è riassunto nel valore coiiapseActionview assegnato all'attributo 

showAs Action. 

Esistono comunque alcuni importanti accorgimenti che descriviamo utilizzando il codice 
dell'applicazione: 

public class MainActivity extends Activity { 

private static final String TAG_LOG = MainActivity . class . getName () ; 
@Override 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 

} 

@Override 

public boolean onCreateOptionsMenu (Menu menu) { 
getMenuInf later ( ) . inf late (R. menu . main, menu) ; 

final Menultem spinnerMenuItem = menu . f indltem (R . id . menuspinner) ; 
final Spinner spinner = (Spinner) spinnerMenuItem. getActionView ( ) 

. f indViewByld (R . id . menu_spinner) ; 
spinner . setOnltemSelectedListener (new OnltemSelectedListener () { 

QOverride 

public void onltemSelected (AdapterView<?> spinner, View view, 
int position, long id) { 
Log. i (TAG_LOG, "In Spinner selected item " 

+ spinner. getltemAtPosition (position) ) ; 

} 

QOverride 

public void onNothingSelected (AdapterView<?> spinner) { 
Log. i (TAG_LOG, "Nothing selected in Spinner"); 

} 

}); 

return true; 

} 

QOverride 

public boolean onOptionsItemSelected (Menultem item) { 
Log. i (TAG_LOG, "Selected item " + item. getTitle () ) ; 
return super . onOptionsItemSelected (item) ; 

} 

} 

Come sempre, la creazione delle opzioni dell' ActionBar avviene all'interno del metodo 
onCreateOptionsMenu o , dove devono essere gestiti gli eventi associati al nostro layout. Quello che il 
sistema là automaticamente è solamente l'espansione o meno del corrispondente layout e la notifica 
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della selezione attraverso l'invocazione del metodo onOptionsItemSelected ( ) . E bene sottolineare 
come tale metodo venga invocato anche nel momento della selezione dell'azione con conseguente 
visualizzazione, nella versione espansa, del layout associato. Gli eventi relativi allo spinner dovranno 
essere implementati in tàse di definizione del menu, come fatto nel nostro esempio attraverso 

l'implementazione diunomtemSelectedListener. 
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Figura 7.10 Visualizzazione dello spinner. 

Lasciamo al lettore la verifica del comportamento descritto osservando i messaggi di log in 
corrispondenza dei diversi passaggi L'espansione o contrazione di una particolare ActionView 
associata a una voce di menu può avvenire in modo programmatico attraverso l'utilizzo dei seguenti 
due metodi: 

public boolean expandActionView () 
public boolean collapseActionView () 

Un modo alternativo per specificare un'Actìonview personalizzata è quello di descriverlaattraverso 
una classe che poi si associa alla voce di menu attraverso l'attributo actionViewClass. Se avessimo 
voluto utilizzare questo attributo avremmo dovuto scrivere la seguente definizione: 

<item 
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androidi : id=" @+id/menu_spinner " 

androidi actionViewClass="android. widget . Spinner" 

android : icon=" @android : drawable/arrow_up_f loat " 
android: showAsAction="ifRoom | collapseActionView" 
android: title=" @st ring/ spinner_action_label " / > 

con il problema che avremmo poi dovuto inizializzare i possibili valori dello spinner, operazione che 
avremmo quindi eseguito all'interno del metodo onCreateOptionsMenu o . 

Utilizzare le schede di navigazione 

Una pattern molto comune nelT utilizzo delle applicazioni su tablet è quello che prevede 
l'associazione di una funzionalità a una particolare scheda (tab) nella parte superiore dello schermo. 
Da quanto visto finora capiamo che il tutto potrebbe essere implementato in modo abbastanza 
intuitivo attraverso l'utilizzo diun'ActionBar per le schede, a ciascuna delle quali possiamo associare 
uno o più fragment. Per dimostrare come questo possa avvenire abbiamo creato il progetto 
TabFragmentTest. Come prima cosa vediamo come sia necessario definire, per l'activity principale, 
un layout che contenga un componente a cui andremo ad agganciare i fragment associati alle diverse 
schede. Si tratta di un semplice layout all'interno del quale è possibile identificare un contenitore come 
quello descritto dal nostro file main . xml! 

<?xml version="l . 0" encoding="utf-8" ?> 

<FrameLayout xmlns : android="http : / / schemas . android . com/apk/ res/ android" 
android : id=" @+id/ anchor_container " 

android: layout_width=" f ill_parent " 
android : layout_height=" f ill_parent " 
android: orientation="vertical" > 
</FrameLayout> 

Per descrivere ciascun fragment da inserire all'interno di ogni scheda abbiamo definito un fragment 
descritto dalla classe TabFragment. Esso contiene una Textview che ci permetterà di distinguere 
un'istanza dalle altre. La gestione delle schede avviene però all'interno della nostra activity, che 
possiamo considerare come organizzata in due parti La prima consente di definire un'interfaccia di 
callback che viene invocata a seguito della selezione di una scheda. Abbiamo quindi implementato il 
seguente listener: 

private class MyTabListener implements TabListener { 
private Fragment fragment; 

/** 

* Creare un'implementazione di MyTabListener per un dato tab 

* Sparam fragment II fragment relativo alla scheda 
*/ 

public MyTabListener (Fragment fragment) { 
this . f ragment= fragment; 

} 

@Override 

public void onTabReselected (Tab tab, FragmentTransaction ft) { 

// Questo metodo viene invocato quando un tab, già selezionato, 
// viene selezionato di nuovo. 

} 

@Override 

public void onTabSelected (Tab tab, FragmentTransaction ft) { 
// Questo viene invocato per notificare una selezione 
f t . add (R. id . anchor_container , fragment ) ; 

} 

@Override 

public void onTabUnselected (Tab tab, FragmentTransaction ft) { 
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// Questo viene invocato per notificare una de-selezione 
f t . remove ( f ragment ) ; 

} 

} 

Notiamo come si tratti di un' implementazione di TabListener, che descrive le operazioni invocate 
a seguito della selezione/deselezione di una scheda. Nel nostro caso vediamo come il corrispondente 
fragment venga aggiunto o rimosso a seguito degli eventi di selezione della scheda. La seconda parte 
prevede la definizione delle schede attraverso una procedura molto sistematica: 

@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_main) ; 
ActionBar actionBar = getActionBar () ; 

actionBar . setNavigat ionMode (ActionBar . NAVIGATION_MODE_TABS ) ; 

Tab tabi = actionBar .newTab () . setlcon (R.drawable . ic_launcher) . setText ("First Tab"); 

Tab tab2 = actionBar .newTab (). setlcon (R.drawable . ic_launcher) . setText ("Second Tab"); 

Tab tab3 = actionBar .newTab (). setlcon (R.drawable . ic_launcher) . setText ("Third Tab"); 

TabFragment fragl = TabFragment . getlnstance ( "FIRST TAB BODY"); 

TabFragment frag2 = TabFragment. getlnstance ("SECOND TAB BODY"); 

TabFragment frag3 = TabFragment. getlnstance ("THIRD TAB BODY"); 

tabi . setTabListener (new MyTabListener (fragl) ) ; 

tab2 . setTabListener (new MyTabListener (f rag2) ) ; 

tab3 . setTabListener (new MyTabListener (f rag3) ) ; 

actionBar . addT ab (tabi) ; 

actionBar . addT ab (tab2) ; 

actionBar. addTab(tab3) ; 

ìnt selectedTablndex = 0; 

if (savedlnstanceState ! =null) { 

selectedTablndex = savedlnstanceState . getlnt (SELECTED_TAG_INDEX_PARAM, 0) ; 

} 

actionBar. set SelectedNavigat ioni tem (selectedTablndex) ; 

} 

Dopo aver impostato il layout di riferimento attraverso il metodo s etContentView ( ) , abbiamo 
ottenuto un riferimento all' ActionBar e poi invocato su di essa il metodo letNavìgationMode ( ) per 
configurarla in modo corretto dal punto divista del look &feel. La costante passata come parametro 
è quella definita da ActionBar .navigation_mode_tabs. Il passo successivo consiste nella creazione 
delle schede vere e proprie, che sono rappresentate da istanze della classe interna ActionBar. Tab che 
si ottengono attraverso il seguente metodo di Factory della classe ActionBar! 

public ActionBar . Tab newTab () 

Attraverso una serie di metodi setxxx ( ) da utilizzare in chaining è infatti possibile definire alcune 
classiche proprietà come l'etichetta, l'immagine, ma soprattutto un'implementazione dell'interfaccia 

TabListener vista Sopra. 

Notiamo come le operazioni permettano di essere avvisati della selezione, deselezione o riselezione 
di una scheda. Nella nostra implementazione abbiamo associato un TabListener al corrispondente 
fragment che possiamo poi aggiungere o togliere dal layout di aggancio in corrispondenza degli eventi 
sull' ActionBar. Ecco che in corrispondenza dell'operazione onTabunseiected o toglieremo il 
fragment associato, mentre in corrispondenza dell'operazione omabseiectect o lo aggiungeremo. 
L'esecuzione di queste operazioni è poi semplificata dalla presenza dell'oggetto FragmentTransaction 
passato come parametro. 

NOTA 

È bene sottolineare come anche in questo caso non si debba inwcare il conmito, la cui 

responsabilità è dell' ActionBar 
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Attraverso le seguenti istruzioni abbiamo creato dei TabListener che abbiamo associato ai 
corrispondenti fragment e alle relative schede: 

TabFragment fragl = TabFragment . getlnstance ( 
TabFragment frag2 = TabFragment . getlnstance ( 
TabFragment frag3 = TabFragment . getlnstance ( 
tabi . setTabListener (new MyTabListener (fragl) 
tab2 . setTabListener (new MyTabListener (frag2) 
tab3 . setTabListener (new MyTabListener (frag3) 

L'esecuzione della nostra applicazione porterà al risultato nella Figura 7.11. 
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Figura 7.11 Accesso ai fragment della modalità con scheda. 



Si tratta di una configurazione che si rivela più utile in un tablet che in uno smartphone, che ha imo 
schermo molto ridotto. Un'ultima considerazione riguarda il latto che la scheda selezionata si debba 
mantenere anche a seguito della rotazione del dispositivo o altra modifica nelle configurazioni. A tale 
proposito abbiamo implementato il metodo di salvataggio nel seguente modo: 

@Override 

protected void onSavelnstanceState (Bundle outState) { 
super . onSavelnstanceState (outState) ; 
// Otteniamo il riferimento alla scheda selezionata 

int selectedTablndex = getActionBar ( ) . getSelectedNavigationlndex ( ) ; 
outState .putlnt ( SELECTED_TAG_INDEX_PARAM, selectedTablndex) ; 

} 

dove è stato utilizzato il metodo getseiectedNavigationindexo per conoscere l'indice della 
scheda selezionata in quel momento. Analogamente a quanto più volte visto, il ripristino dello stato 
avviene attraverso le seguenti righe di codice aggiunte alla fine del metodo onCreate ( ) : 

int selectedTablndex = 0; 

if (savedlnstanceState ! =null) { 

selectedTablndex = savedlnstanceState . getlnt (SELECTED_TAG_INDEX_PARAM, 0); 

} 

Qui il metodo utilizzato per la selezione della scheda è setSelectedNavigationltem ( ) . 



Utilizzare la navigazione drop down 

Nel paragrafo precedente abbiamo visto come F ActionBar permetta l'implementazione di alcuni 
pattern di usabilità e di supporto alla navigazione. Si tratta più che altro di specifiche modalità di 
visualizzazione come quella che prende il nome di navigazione drop down, che non si differenzia di 
molto da quanto già fatto attraverso l'utilizzo di uno spinner, e di cui possiamo personalizzare le 
opzioni il look &feel attraverso opportuni documenti di layout. Per descrivere questa modalità di 
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visualizzazione, utilizziamo ancora un esempio che abbiamo inserito all'interno del progetto 
DropDownNavigationTest, di cui mostriamo immediatamente il risultato attraverso la Figura 7.12. 
Notiamo la visualizzazione di uno spinner all'interno dell' ActionBar con alcune possibilità 
selezionando le quali si ha la modifica dell'etichetta centrale che è stata definita in un fragment. 
Abbiamo infatti creato la classe LabelFragment che descrive un componente che permette la 
visualizzazione di una sola Textview alfine di poterne riconoscere le diverse istanze. Selezionando le 
voci dello spinner otteniamo quindi la modifica del fragment centrale, che mostrerà valori di etichetta 
diversi. A livello di implementazione si tratta di un pattern abbastanza semplice che si implementa 
seguendo alcuni semplici passi. 
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Figura 7.12 Utilizzo della navigazione definita come drop down. 

Per quello che riguarda la logica di creazione di questo spinner osserviamo il seguente codice: 

dOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 

mSpinnerAdapter = ArrayAdapter . createFromResource (this , 

R . array . navigation_options , R . layout . spinner_item) ; 
ActionBar actionBar = get ActionBar () ; 

actionBar . setNavigationMode (ActionBar . NAVIGATION_MODE_LIST) ; 

actionBar . setListNavigationCallbacks (mSpinnerAdapter, mOnNavigationListener ) ; 
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if ( savedlnstanceState == nuli) { 

mCurrentFragment = LabelFragment . getLabelFragment (mSpinnerAdapter . getltem ( 0) 
. toString ( ) ) ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 

. add (R . id . container , mCurrentFragment) . commit () ; 

} 

} 

Innanzitutto notiamo come vi sia la creazione di Uno SpinnerAdapter direttamente dalla risorsa di 
tipo array che ne contiene le varie opzioni specificando il layout per ogni possibile valore. Per tare 
questo abbiamo utilizzato il metodo createFromResource ( ) della classe ArrayAdpater, che è appunto 

Uno SpinnerAdapter. 

NOTA 

Il lettore si sarà chiesto come mai vi sia stata la necessità di una nuova interfaccia oltre quella 
generica di adapter. Come sappiamo un adapter è un componente che ha la responsabilità di fornire 
le view che un particolare viewcroup utilizzerà per la visualizzazione di un numero elevato di 
informazioni. Se pensiamo però a uno spinner possiamo notare come le diverse opzioni abbiano 
due diverse possibilità di visualizzazione: quella relativa all'opzione selezionata e quella relativa allo 
spinner quando viene espanso come nella Figura 7.12. 

Dopo aver creato l' adapter e ottenuto il riferimento all' ActionBar, impostiamo la modalità di 
navigazione drop down attraverso il seguente metodo: 

public abstract void setNavigationMode (int mode) 

a cui passiamo come parametro la seguente costante ActionBar .navigation_mode_list. Infine 
invochiamo il seguente metodo: 

public abstract void setListNavigationCallbacks (SpinnerAdapter adapter, 
ActionBar . OnNavigationListener callback) 

a cui passiamo come parametri il riferimento allo SpinnerAdapter e un'implementazione 
dell'interfaccia ActionBar. OnNavigationListener che ci consentirà di gestire gli eventi di selezione. 
Nel nostro caso abbiamo implementato tale listener nel seguente modo: 

private ActionBar . OnNavigationListener mOnNavigationListener = new 
ActionBar . OnNavigationListener ( ) { 

SOverride 

public boolean onNavigationltemSelected (int itemPosition, long ìtemld) { 
mCurrentFragment = LabelFragment . getLabelFragment ( 

mSpinnerAdapter . getltem (itemPosition) . toString ( ) ) ; 
getSupportFragmentManager ( ) . beginTransaction ( ) 

. replace (R. id. container, mCurrentFragment) 

. addToBackStack (nuli) .commit (); 
mSpinnerAdapter . getltem ( itemPosition) ) ; 
return false; 

} 

}; 

Vediamo come non si faccia altro che modificare il fragment visualizzato corrispondente alla voce 
selezionata. Si tratta ormai di codice noto che il lettore potrà testare con semplicità. 

ActionBarSherlock: l'ActionBar prima di 

Honeycomb 

Come abbiamo più volte sottolineato, l' ActionBar è disponibile dalla versione 3.0 della piattaforma 
e la Compatibility Library, che ci è venuta in soccorso diverse volte come nel caso dei fragment, 
questa volta non ci può aiutare. La nostra applicazione UGHO ha dichiarato però di voler supportare 
le versioni della piattaforma precedenti e in particolare dalla 2. 1 (Eclair - Api Level 7), per cui ci 
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troviamo di fronte a un bivio: utilizzare l'ActionBar oppure no? Nella maggior parte delle applicazioni 
attualmente sul Play Store la risposta è stata positiva, grazie anche all'aiuto di un framework che si 
chiama ActionBarSheriock e che attraverso un attento utilizzo dei temi permette di avere lo stesso 
layout per tutte le versioni della piattaforma. Purtroppo è un framework piuttosto invasivo in quanto 
definisce le proprie specializzazioni della classe Activìty, le quali utilizzano a loro volta delle classi 
che delegano o meno il proprio funzionamento alle API standard se disponibili 

Il primo passo consiste nell'installazione di questo framework, che possiamo trovare all'indirizzo 

http : //actionbarsherlock . com/. 

Scarichiamo lo ZIP dell'ultima versione disponibile (in questo momento la 4.3. 1) e 
decornprimiamolo in una cartella temporanea ottenendo quanto mostrato nella Figura 7.13. 
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Figura 7.13 II contenuto del file scaricato da actionbarsherlock.com. 

Notiamo come ci siano diverse cartelle; quella di nome actionbarsherlock (tutto minuscolo) 
contiene la libreria vera e propria. 

NOTA 

Le altre contengono ulteriori estensioni per le quali rimandiamo alla documentazione sul sito. 

Prendiamo la prima cartella nella figura (rmorninandola aggiungendo le maiuscole e poi come 
ActionBarSherloc k) e copiandola nella cartella che abbiamo chiamato libraries all'interno del nostro 
progetto, come possiamo vedere nella Figura 7.14. 
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Figura 7.14 Abbiamo copiato il progetto nella cartella libraries nel nostro progetto. 

Android Studio dovrebbe accorgersi della modifica e mostrare una struttura del progetto come 
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quella nella Figura 7.15. 



Project 



UG HO (~ / And roid Stud ioProj ects / UC H 0) 



► CD .idea 

► CD gradle 
▼ CD libraries 

▼ CD ActionBarSherlock 

► Qlibs 

► C]res 

► Dsrc 

► E] test 

2 And roid Manifest xml 

2 lint.xml 

& pom.xml 

[iii project.properties 

0 README.md 

► CaUCHO [UCHO-UCHO] 
(•) build.gradle 

B gradlew 
El gradlew.bat 
L ■ 1 1 local.properties 
♦^README.md 

settings.gradle 
31 UCHO.iml 
DI UCHO-UCHO.iml 
•i External Libraries 



Figura 7.15 La struttura del progetto dopo l'aggiunta di ActionBarSherlock. 

A questo punto dobbiamo istruire il nostro tool di build Gradle alla presenza della nuova libreria. Il 
primo passo consiste nelT editare il file di nome settings.gradle nella cartella principale del nostro 
progetto (evidenziata nella figura precedente) aggiungendo la dipendenza nel seguente modo: 

include ':UGHO', ': libraries : ActionBarSherlock ' 

Il lettore noterà come Android Studio inizi a eseguire il build anche se non abbiamo finito, in quanto 
il progetto importato è al momento un progetto per eclipse e deve essere trasformato per il nostro 
nuovo tool. Questo comporta la necessità del corrispondente file per Gradle, che dovrà essere creato 
nella cartella UGHOMbraries/ActionBarSherlock. Il file, di nome buìid.gradie, dovrà essere il 
seguente: 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/maven2' } 

} 

dependencies { 

classpath ' cora. android . tools . build : gradle : 0 . 4 . + ' 
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} 

apply plugin : ' android-library ' 

dependencies { 

compile f iles ( ' libs/ android-support-v4 . jar ' ) 

} 

android { 

compileSdkVersion 17 
buildToolsVersìon "17.0.0" 

def aultConf ig { 

minSdkVersion 7 
targetSdkVersion 16 

} 

sourceSets { 
mairi { 

manif est . srcFile 1 AndroidManif est . xml ' 

java.srcDirs = [ 1 src ' ] 

resources . srcDirs = [ ' src ' ] 

aldi . srcDirs = [ ' src ' ] 

renderscript . srcDirs = [ ' src 1 ] 

res . srcDirs = [ ' res ' ] 

assets . srcDirs = ['assets'] 

} 

instrumentTest . setRoot ( ' tests ' ) 

} 

} 

La parte iniziale è la stessa del progetto che abbiamo creato inizialmente e consente la definizione 
del repository di riferimento e del plug-in. Da notare solamente la sintassi o . 4 . +, che permette di 
ottenere automaticamente l'ultima versione disponibile. La riga successiva consente di utilizzare un 
plug-in diverso in quanto si vuole utilizzare questo progetto come libreria. Infine abbiamo evidenziato 
la definizione di un sourceset che ci permette di utilizzare, con Android Studio, i progetti che hanno 
una struttura tipica di un progetto per eclipse. Attraverso le definizioni evidenziate stiamo istruendo 
Gradle relativamente a dove si trovano i vari sorgenti Questa configurazione è importante perché è la 
stessa che si utilizza nel caso in cui si volesse importare in Android Studio un progetto realizzato con 
eclipse. 

Il passo successivo consiste nella definizione della libreria all'interno del nostro progetto editando il 
corrispondente file buiid.gradie, che ora diventa il seguente: 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/maven2' } 

} 

dependencies { 

classpath ' com . android .tools.build:gradle:0.4.+' 

} 

} 

apply plugin: 'android' 

dependencies { 

compile prò ject ( ' : libraries :ActionBarSherlock ' ) 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdkVersion 7 
targetSdkVersion 16 

} 
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} 

Nella parte evidenziata vediamo come sia stata rimossa la dipendenza dalla Compatibility Library 
in quanto ereditata da quella relativa al progetto ActionBarSherlock che abbiamo messo al suo 
posto. 

NOTA 

La configurazione che abbiamo appena realizzato potrebbe richiedere ulteriori accorgimenti a 
seguito dell'evoluzione del plug-in per Gradle. Nel caso in cui vi fossero degli errori è comunque 
bene andare, con prompt di comando, nella cartella del progetto e digitare il comando ./gradlew clean, 
il quale consente appunto di pulire le configurazioni precedenti di Gradle. 

A questo punto la nostra applicazione dovrebbe essere configurata in modo da utilizzare questo 
framework che, come accennato, ha lo svantaggio di portare con sé un grosso grado di dipendenza. 
Una trattazione completa di ActionBarSherlock richiederebbe molto spazio in quanto, insieme alla 
gestione delle opzioni, permette la creazione di tutte le funzionalità descritte con il vantaggio di 
estenderle anche alle versioni precedenti la 3.0. Per questo motivo abbiamo deciso di implementare 
solamente alcune azioni in sostituzione del pulsante di login e di invio dei dati di registrazione. 
Vedremo poi gli aspetti che interessano questa funzionalità man mano che completeremo 
l'applicazione UGHO. 

Iniziamo da quello più semplice, cioè quello relativo al login che in precedenza avevamo 
implementato nella classe LoginActivity, che ricordiamo rappresentava un semplice esempio di 
attività poiché estendeva direttamente la classe Activity. Per poter utilizzare ActionBarSherlock è 
necessario però fare alcune configurazioni. La prima riguarda il tema dell' app Reazione, che dovrà 
estendere uno dei temi del framework tra i seguenti: 

Theme . Sherlock 

Theme . Sherlock . Light 

Theme . Sherlock . Light . DarkActionBar 

Nel nostro caso questo si traduce nella modifica della definizione del nostro tema di riferimento nel 
file styie.xmi nel seguente modo: 

<style name="AppBaseTheme" parent=" Theme . Sherlock . Light .DarkActionBar "> 

</style> 

Un aspetto importante è che il tema di Sherlock già incapsula le variazioni dovute alla diversa 
versione, per cui questo ci consente di eliminare le definizioni di stile che avevamo definito nelle 
cartelle values-vll e values-vl4. Possiamo quindi cancellare le corrispondenti cartelle a meno che 
non vi siano altre definizioni relative ad altri componenti o parti dell'applicazione. Per quello che 
riguarda la definizione della nostra attività dobbiamo poi modificare la classe padre ereditando ora 
dalla classe com. actionbarsherlock . app . SherlockActivity. Prima di proseguire trasformando il 
pulsante di login in un' action nelT ActionBar, facciamo una verifica della corretta installazione e 
configurazione del framework. Utilizziamo un dispositivo nella versione 2.1 o comunque inferiore alla 
3.0 oppure creiamo, come nel nostro caso, un AVE) ed eseguiamo la nostra applicazione. In caso di 
un'errata configurazione la barra nella parte superiore del dispositivo appare come nella Figura 7. 16, 
tipica delle prime versioni di Andro id. 
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Figura 7.16 Qualcosa è andato storto nella configurazione di ActionBarSherlock. 



Se invece tutto è stato configurato nel migliore dei modi il risultato dovrebbe essere quello nella 
Figura 7.17 in cui compare l'ActionBar. 

ATTENZIONE 

Nella versione disponibile al momento in cui si scrive, I' ActìonBar non è visibile in preview in Android 
Studio anche se si specifica lo stile corretto. Questo perché la gestione dell'ActionBar non è solo una 
questione di stili e temi ma presuppone anche l'esecuzione di codice che la preview non è in grado 
di fare. 
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Figura 7.17 L'ActionBar compare anche per Android 2.1 . 

La dimostrazione di quanto detto nella nota precedente si può verificare impostando il tema 
dell'applicazione senza poi estendere le classi del framework sia per le activity sia per i fragment. 

Tornando alla nostra LoginActìvity, abbiamo aggiunto l'ActionBar su tutte le versioni della 
piattaforma, ma ora vogliamo impostare l'opzione di login come action e non come pulsante. 

NOTA 

Impostare l'operazione di login come pulsante o come action dell' ActionBar può essere un buon tema 
di discussione dal punto di vista dell'usabilità e del design. Nel nostro caso lo prendiamo come 
pretesto per dimostrare l'utilizzo dell' ActionBar con il framework Sherlock. Sicuramente in questo 
caso, come in generale, l'utilizzo di un'action permette di avere più spazio a disposizione sullo 
schermo. 

Dopo aver esteso la classe SherlockActivity dobbiamo eseguire Yoverride dei metodi che ci 
permettono di definire il pulsante di azione. Questa volta dobbiamo però fare attenzione che il metodo 
da estendere non è quello ereditato da Activity ma quello ereditato da SherlockActivity, che 
utilizza una versione personalizzata di Menu. Definiamo la seguente risorsa di menu nel file 

sherlock_login . xml nella cartella res/menu/: 

<menu xmlns : android="http : / /schemas .android . com/ apk/res/ android" > 
<item 
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android : id=" @+id/ action_login" 
android: title=" @string/action_login" 
android: icon=" Sdrawable/ ic_login" 
android: orderInCategory="100" 
android: showAsAction=" if Room" / > 

</menu> 

ed eseguiamo Voverride del seguente metodo: 

HOverride 

public boolean onCreateOptionsMenu (Menu menu) { 

Menulnflater inflater = getSupportMenuInf later ( ) ; 
inflater.inflate (R .menu . sherlock_login, menu) ; 
return super . onCreateOptionsMenu (menu) ; 

} 

Potrebbe sembrare analogo a quello che abbiamo ridefinito nel modo classico ma invece presenta 
alcune differenze sostanziali. Innanzitutto non si nota, in quanto importati nella parte iniziale della 
classe, ma le classi Menu e Menuinfiater sono quelle di ActionBarsheriock, che precisamente 
vengono importate nel seguente modo: 

import com. actionbarsherlock .view. Menu; 

import com. actionbarsherlock . view . Menulnflater ; 

Questo è anche il motivo per cui il Menulnflater non si ottiene nel modo consueto ma attraverso il 
metodo getSupportMenuInf later ( ) che abbiamo ereditato dalla classe the rlockActivity. Un 
aspetto interessante riguarda il fatto che l'IDE non ci suggerisce Voverride dei metodi analoghi definiti 
della classe Activity. Questo perché la classe the rlockActivity li definisce come final nel 
seguente modo: 

public final boolean onCreateOptionsMenu (android . view .Menu menu) { 
/* Codice compilato */ 

} 

public final boolean onPrepareOptionsMenu (android . view .Menu menu) { 
/* Codice compilato */ 

} 

public final boolean onOptionsItemSelected (android. view. Menultem item) { 
/* Codice compilato */ 

} 

L'implementazione è quella che esegue tutto il lavoro "sporco" di conversione tra i due mondi 
Il secondo metodo di cui faremo Voverride è quello relativo alla selezione dell'opzione associata 

all'identificatore r. id.action_iogin come definito nella nostra risorsa di tipo menu. Abbiamo 

definito il seguente metodo: 

HOverrìde 

public boolean onOptionsItemSelected (Menultem item) { 
if (item.getltemld ( ) == R . id . action_login) { 
doLogin ( ) ; 

} 

return super . onOptionsItemSelected (item) ; 

} 

Qui si richiama il metodo doLogin ( ) , a cui abbiamo tolto il parametro di tipo view che ci serviva 
per la gestione dell'evento di onClick che dobbiamo ricordarci di eliminare dal layout contenuto nel 

file activity_login.xml insieme a tutto ilButton. 
NOTA 

In questa occasione ricordiamoci anche di eliminare ogni riferimento al Button all'interno della classe 
LoginActivity, come per esempio in occasione dell'impostazione del font personalizzato. 

Se eseguiamo l'applicazione il risultato è quello nella Figura 7.18. 
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Figura 7.18 Definizione dell'action per l'invio dei dati di login. 

Come possiamo notare è stata inserita l'icona per la selezione dell'azione di login anche in 
dispositivi conAndroid precedenti la 3.0. L'immagine là riferimento a un AVD conAndroid 2.1, 
lasciamo al lettore la verifica del risultato con le altre versioni della piattaforma. 

Ci spostiamo ora alla schermata per la registrazione che, ricordiamo, utilizza dei fragment solo per 
la gestione del nostro calendario personalizzato. Inizialmente la classe fcegisterActivity estendeva 
la classe FragmentActivity che ora diventa la classe the rlockFragmentActivity. Analogamente a 
quanto fatto in precedenza definiamo la risorsa di tipo menu all'interno del file 

sherlock_register . xml! 

<menu xmlns : android="http : / / schema s . android . com/ apk/res/ android"> 
<item 

android: id="@+id/action_register" 

android: title=" Sstring/ action_register " 
android: icon=" Sdrawable/ ic_register" 
android: orderInCategory="100" 
android : showAsAction=" if Room" / > 

</menu> 

e quindi eseguito 1 ' override dei seguenti metodi: 
@Override 

public boolean onCreateOptionsMenu (Menu menu) { 

Menulnflater inflater = getSupportMenuInf later ( ) ; 
inflater . inf late (R. menu . sherlock_register, menu) ; 

return super . onCreateOptionsMenu (menu) ; 



SOverride 

public boolean onOptionsItemSelected (Menultem item) { 
if (item.getltemld() == R. id. action_register) { 
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doRegistration () ; 

} 

return super . onOptionsItemSelected (item) ; 

} 

dove sono state fatte le modifiche analoghe al caso precedente in relazione all'eliminazione del 
pulsante e dei relativi riferimenti all'interno dell' activity. Otteniamo il risultato mostrato nella Figura 
7.19. 
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Figura 7.19 La schermata di registrazione adattata all'utilizzo di ActionBarSherlock. 

Il lettore avrà compreso quello che è il meccanismo di utilizzo di questo framework. Insieme a una 
personalizzazione dei temi si utilizzano delle particolari classi che i nostri activity e fragment dovranno 
estendere da cui ereditare i metodi per la gestione dei menu in modo indipendente dalla piattaforma. 



Conclusioni 

In questo capitolo abbiamo affrontato un argomento che potrebbe sembrare marginale ma che è 
invece di fondamentale importanza, ovvero l'ActionBar. È un componente alla base della maggior 
parte dei pattern UI consigliati da Google nella realizzazione delle applicazioni Andro id. Non si tratta 
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di un argomento banale in quanto richiede una buona conoscenza della piattaforma specialmente per 
quello che riguarda la gestione degli stili e dei temi Abbiamo anche affrontato una problematica non 
indifferente legata al fatto che l'ActionBar è stata introdotta solamente dalla versione 3.0 (API Level 
11) della piattaforma senza essere sanata dalla Compatibility Library. Abbiamo poi descritto come 
installare tale libreria gestendo le varie dipendenze e abbiamo realizzato alcuni semplici esempi 
applicati alla nostra applicazione UGHO, per la quale il viaggio non è ancora finito in quanto mancano 
due argomenti fondamentali come la gestione della persistenza e l'accesso alle basi dati esterne, che 
saranno argomento dei prossimi capitoli 
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Capitolo 8 



Strumenti di persistenza 



Nei capitoli precedenti ci siamo occupati di tutto ciò che riguarda la gestione della UI attraverso la 
definizione delle diverse activity e l'utilizzo di fragment per quanto opportuno fino all'utilizzo delle 
funzionalità messe a disposizione dall' ActionBar. Un'applicazione Andro id, come ogni altra 
applicazione mobile, non è solamente interfaccia ma utilizza tutta una serie di strumenti per la 
persistenza delle informazioni che saranno argomento di questo capitolo. La prima parte della nostra 
applicazione UGHO implementa un meccanismo di registrazione e login. Inizialmente l'utente vede 
una schermata con la possibilità di entrare come anonimo, eseguire il login oppure registrarsi 
attraverso un apposito form di registrazione. A questo punto l'applicazione accederà a un server in 
remoto e riceverà indietro le informazioni relative all'utente, che dovranno quindi essere rese 
persistenti localmente. Questo primo scenario è quello che ci permetterà di introdurre le API per la 
gestione delle preferenze, ovvero degli strumenti con cui possiamo rendere persistenti piccole quantità 
di informazioni con alcune limitazioni sul loro tipo; potremo infatti rendere persistenti solamente String 
e tipi primitivi Implementeremo un semplice pattern che renderà l'oggetto userModei persistente. A 
questo punto faremo in modo che la parte iniziale dell'applicazione si accorga se l'utente è loggato 
oppure no consentendo poi l'operazione di logout. In questo caso le informazioni non sono molte per 
cui non c'è la necessità di utilizzare qualcosa di più complesso come un vero e proprio DBMS 
(DataBase Management System). 

Come detto nel Capitolo 1 , le applicazioni per Andro id si programmano in Java per cui sarà 
possibile utilizzare tutte le API che la piattaforma Java ci offre. Si potranno quindi scrivere e leggere 
dei file sul file system associato all'utente dell'applicazione. A queste API dedicheremo poco spazio in 
quanto non strettamente legate alla piattaforma Android e passeremo invece a un aspetto 
fondamentale, ovvero l'utilizzo di SQLite come DB. In questa fase ci occuperemo dell'inserimento 
delle informazioni da gestire in locale. Vedremo come creare un DB e gestire una sorta di DAO 
(Data Access Object) per l'esecuzione di operazioni di CRUD sulle informazioni che abbiamo già 
visualizzato all'interno della lista nel Capitolo 6. Approfitteremo di questa nuova soluzione per vedere 
anche le implementazioni di Adapt e r che estraggono le informazioni dall'oggetto cursor che permette 
di accedere ai risultati delle query. 

L'ultima parte del capitolo sarà invece dedicata a un componente di fondamentale importanza che 
si chiama content provider. A differenza di quello che succede per i DB SQLite che sono, se non 
configurati diversamente, privati dell'applicazione che li ha creati, un content provider è per 
definizione qualcosa che può essere condiviso tra più applicazioni Vedremo come, attraverso 
un'interfaccia REST (REpresentational State Transfert) sia possibile eseguire le classiche 
operazioni di CRUD su una base dati che non è necessariamente un DB SQLite ma che, 
teoricamente, potrebbe essere rappresentata da una struttura su file, in memoria o remota. Anche qui 
il lavoro da fare è moltissimo per cui procediamo. 
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Utilizzo delle prefereze 

Una parte molto importante di ogni applicazione Android (ma lo stesso succede anche in altri 
ambienti come quello iOS) è quella delle preferenze o settings. Si tratta di una serie di schermate 
attraverso le quali l'utente può impostare alcune informazioni di configurazione legate a una o più 
applicazioni. In ciascun dispositivo Android, le preferenze rappresentano una vera a propria 
applicazione, come quella nella Figura 8. 1 . È una sezione di ogni applicazione abbastanza standard 
per la quale la piattaforma ha fornito degli strumenti in grado di costruire in modo semplice le UI 
gestendo in modo quasi automatico la persistenza delle hformazioni. Sebbene non siano state 
progettate esattamente per questo, le stesse API di gestione delle preferenze vengono utilizzate per la 
persistenza di informazioni di piccola entità come nel nostro caso, in cui vogliamo memorizzare le 
informazioni dell'utente correntemente loggato. Utilizzeremo poi queste informazioni permettendone 
l'editing attraverso gli strumenti messi a disposizione dalla piattaforma per la gestione delle preferenze. 

Gestire la lettura di questo tipo di informazioni è quasi banale e implica l'utilizzo del seguente 
metodo definito in Context che anche le nostre activity ereditano: 

public abstract SharedPref erences getSharedPref erences (String name, int mode) 

Questo consente di accedere a un'istanza della classe SharedPref erences associata a un 
particolare nome e a un identificatore dei permessi di accesso da parte delle altre applicazioni. Il 
valore di default del mode è quello descritto dalla costante statica context .mode_private, che indica 
che le informazioni sono accessibili solamente ai componenti di una stessa applicazione. Nel caso in 
cui si volessero rendere queste informazioni accessibili anche alle altre applicazioni in lettura, la 
costante da utilizzare sarà context .mode_world_readable, mentre per l'accesso in scrittura basterà 
specificare il valore di mode context . mode_world_writeable. 



316 



A Debug USB collegato 

Impostazioni 



Q Bluetooth 



3 Utilizzo dati 
Altro... 

DISPOSITIVO 

Audio 
O Display 
S Memoria 
8 Batteria 
□ Applicazioni 

PERSONALE 

# Accesso alla posizione 

Q C3 



Figura 8.1 Le impostazioni di un Nexus 4 con Android 4.2.2. 
ATTENZIONE 

Il permesso di accesso in scrittura non comprende implicitamente quello di lettura. Questo significa 
che potremmo, un po' paradossalmente, dare il permesso di scrittura senza quello di lettura. 

Come accennato si tratta di un metodo definito in Context che anche le activity ereditano. Questi 
componenti hanno anche la possibilità di utilizzare un overload del metodo precedente che utilizza 
come default per le preferenze il nome dell'attività stessa permettendo quindi solamente 
l'impostazione del mode: 

public SharedPref erences getPref erences (int mode) 

Una volta ottenuto il riferimento all'oggetto di tipo SharedPref erences possiamo utilizzare tutta una 
serie di metodi getxxx ( ) che ci consentono di accedere ai valori di configurazione associati a una 
particolare chiave per i principali tipi primitivi e la Strìng. Vedremo successivamente come accedere 
alla e-mail associata all'utente attraverso un'istruzione del tipo: 

final SharedPref erences prefs = ctx . getSharedPref erences (PREFS_NAME, 
Context .MODE_PRIVATE) ; 

final String email = prefs . getString (EMAIL_KEY, def aultValue ) ; 
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Notiamo come il metodo getstringo disponga di imprimo parametro che rappresenta la chiave 
del dato da leggere, e un secondo parametro che è il valore di delàult da ritornare nel caso in cui il 
risultato fosse nuli. 

Molto interessante è invece la modalità con cui le informazioni vengono salvate e quindi modificate. 
In questo caso la stessa classe sharedPref erences diventa Factory per un oggetto di tipo 
sharedPreferences. Editor il quale ci permette di gestire le informazioni come fossero all'interno di 
ima transazione. Il codice per la modifica della precedente informazione di e-mail sarebbe questo: 

final SharedPreferences prefs = ctx . get SharedPref erences (PREFS_NAME , 
Context . MODE_PRIVATE ) ; 

SharedPref erences . Editor editor = prefs .edit () ; 

editor .putString (EMAIL_KEY, mEmail) ; 
editor . commit ( ) ; 

Dall'oggetto di tipo sharedPreferences otteniamo l'oggetto di tipo Editor attraverso il metodo di 
Factory edit ( ) . Attraverso una serie di metodi putxxx ( ) che riflettono i corrispettivi metodi getxxx ( ) 
impostiamo i valori da memorizzare per poi eseguire il commit ( ) sull'Editor per renderli effettivi. Da 
osservare come sia possibile anche eliminare alcuni valori attraverso l'utilizzo del metodo 

public abstract SharedPref erences . Editor remove (Strìng key) 

mentre il metodo 

public abstract SharedPref erences . Editor clear ( ) 

consente la cancellazione di tutte le informazioni. 

Prima di vedere come questi strumenti possano essere utilizzati nella nostra applicazione per la 
persistenza delle informazioni del profilo di un utente, facciamo notare l'esistenza della classe 
Pref erenceManager, la quale dispone di questo metodo: 

public static SharedPreferences getDef aultSharedPref erences (Context context) 

il quale ci permette di ottenere un oggetto di tipo SharedPref e r enee. Ma che differenza esiste tra 
gli oggetti di tipo sharedPreferences creati in precedenza e quello ottenuto dalla classe 
Pref erenceManager ' Per quello che riguarda il suo utilizzo non vi è alcuna differenza in quanto si tratta 
comunque di un'istanza della stessa classe sharedPreferences. Il grosso vantaggio èche l'oggetto 
ottenuto è esattamente lo stesso che verrà utilizzato dal framework delle preferenze per la persistenza 
delle informazioni. Se, come nel nostro caso, vogliamo editare le informazioni di profilo attraverso 
un'interfaccia che utilizza le API standard, è bene ricorrere a tale metodo. 

Per questo motivo abbiamo aggiunto alla nostra classe userModei, che descrive le informazioni 
associate a un utente e i metodi per il salvataggio e ripristino delle informazioni di profilo. In 
particolare il metodo per il salvataggio dei dati di profilo è questo: 

public void save (final Context ctx) { 

final SharedPreferences prefs = Pref erenceManager . getDef aultSharedPref erences (ctx) ; 

SharedPref erences . Editor editor = pref s . edit () ; 

editor .putString (USERNAME_KEY, mUsername) ; 

editor .putString (EMAIL_KEY, mEmail) ; 

editor .putLong (BIRTHDATE_KEY, mBìrthDate) ; 

editor .putString (LOCATION_KEY, mLocation) ; 

editor . commit ( ) ; 

} 

Abbiamo Utilizzato Pref erenceManager e Ottenuto l' Oggetto SharedPreferences, che poi 

impareremo anche a editare in modo visuale. Abbiamo poi ottenuto il riferimento all'Editor, 
attraverso il quale abbiamo memorizzato i valori dei vari attributi associandoli ad altrettante chiavi che 
abbiamo definito attraverso delle costanti Infine, per rendere effettive le modifiche, abbiamo invocato 
il metodo commit o sull'Editor. Da notare come il metodo save o necessiti del Context come 
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avviene nella maggior parte dei metodi della piattaforma Andro id. 

Per quello che riguarda la lettura delle informazioni di profilo abbiamo creato il seguente metodo: 

public static UserModel load (final Context ctx) { 

final SharedPref erences prefs = Pref erenceManager . getDef aultSharedPref erences (ctx) ; 
long birthDate = pref s . getLong (BIRTHDATE_KEY, 0 ) ; 
UserModel userModel = nuli; 
if (birthDate != 0) { 

userModel = new UserModel (birthDate) ; 

userModel .mUsername = pref s . getString (USERNAME_KEY, nuli); 
userModel .mEmail = pref s . getString (EMAIL_KEY, nuli) ; 
userModel .mLocation = pref s . getString (LOCATION_KEY, nuli); 
return userModel; 

} 

return userModel; 

} 

Possiamo osservare come si ottenga il riferimento all'oggetto SharedPref erences attraverso 
pref erenceManager e come si legga inizialmente il valore relativo alla data di nascita. E infetti l'unica 
informazione obbligatoria. Nel caso in cui non fosse presente significherebbe l'assenza di un 
qualunque profilo e quindi ritorniamo nuli. Chi utilizza il metodo ioad ( ) dovrà poi gestire il caso. Se 
invece è presente una data di nascita significa che l'utente è loggato o comunque esiste, per cui 
abiliteremo un'opzione dilogout, che abbiamo implementato attraverso il seguente metodo: 

public void logout (final Context ctx) { 

Pref erenceManager . getDef aultSharedPref erences (ctx) 
. edit ( ) . clear ( ) . commit ( ) ; 

} 

Da notare come l'utilizzo dello static factory metod ci permetta di implementare il chaining 
cancellando tutte le informazioni del nostro profilo con un'unica istruzione. Queste modifiche ci 
devono far riflettere su cosa si intenda per utente loggato oppure no. Nel nostro caso supporremo 
che un utente loggato abbia memorizzate le informazioni relative all'oggetto userData nelle preferenze. 
L'assenza delle informazioni corrisponderà a un utente non loggato. Questo è il caso in cui il metodo 

UserData. load () ritorna un valore nuli. 

NOTA 

Un aspetto fondamentale di questo nuovo modo di gestire l'oggetto userData è che ciascuna attività 
potrà ottenerne un riferimento attraverso il metodo ioado evitando di passarlo come parametro e 
quindi di eseguire le operazioni di serializzazione e deserializzazione, che possono essere pesanti. 
Il lettore potrebbe obiettare dicendo che comunque si rende necessaria ogni volta una lettura delle 
configurazioni. Bisogna valutare prò e contro in base anche alle informazioni da gestire. A favore di 
questa nuova modalità diciamo comunque che consente di rendere le diverse activity indipendenti 
dalla modalità con cui vengono invocate. Questa è anche la modalità con cui le diverse attività 
accedono alle informazioni nel DB. 

Il passo successivo consiste nell'integrazione del nuovo profilo all'interno della nostra applicazione 
iniziando dall'attività di splash. Nel caso in cui l'utente fosse già loggato non dovremo passare per la 
FirstAccessActivity ma andare direttamente all'attività di menu descritta dalla classe MainActivity. 
Se l'utente non è loggato seguiremo lo stesso percorso già esistente. Questa logica ci porta a 
modificare il metodo goAhead O della classe TouchspiashActìvity come segue: 

private void goAheadt) { 

final UserModel userModel = UserModel. load (this ) ; 
Class<? extends Activity> destinationActivity = nuli; 
if (userModel == nuli) { 

destinationActivity = FirstAccessActivity . class; 
} else { 

destinationActivity = MenuActivity . class; 

} 

final Intent intent = new Intent(this, destinationActivity); 

319 



startActivìty (intent ) ; 
finish ( ) ; 

} 

Vediamo come si utilizzi il metodo ioado per ottenere il riferimento all'oggetto tserModei e quindi 
verificarne la presenza. In caso positivo si andrà alla schermata di menu, mentre in caso negativo 
andremo alla schermata di primo accesso. Dobbiamo mettere l'utente nelle condizioni di potersi 
loggare e poi creare e rendere persistente l'oggetto userModei a seguito di un accesso anonimo, un 
login o una registrazione. Anche stavolta dobbiamo fare alcune modifiche legate al fatto che, nel caso 
di accesso anonimo, si deve comunque inserire la data di nascita. Abbiamo modificato la nostra classe 
in modo da poter utilizzare il nostro calendario: 

public class FirstAccessActivity extends SherlockFragmentActivity 
implements FirstAccessFragment . FirstAccessListener , 
CalendarGraphChooserDialogFragment . OnGraphCalendarChooserListener { 

/ / Come prima 

private static final String CALENDAR_FRAGMENT_TAG = "DATE SELECTION TAG"; 

public void enterAsAnonymous ( ) { 

CalendarGraphChooserDialogFragment dateDialog = 
CalendarGraphChooserDialogFragment . 

getCalendarChooserDialog (new DateO ) ; 
dateDialog. show (getSupportFragmentManager ( ) , CALENDAR_FRAGMENT_TAG) ; 

} 

@Override 

public void dateSelected (CalendarGraphChooserDialogFragment source, 

Date selectedDate) { 
UserModei userData = UserModei . create ( selectedDate . getTime ()) ; 
userData . save (this) ; 

final Intent anonymouslntent = new Intent (this, MenuActivity . class ) ; 
startActivity (anonymouslntent) ; 
finish ( ) ; 

} 

SOverride 

public void selectionCanceled (CalendarGraphChooserDialogFragment source) { 

} 

} 

Vediamo come in corrispondenza della pressione del pulsante di accesso anonimo non si fa altro 
che visualizzare il nostro calendario e selezionare una data. Nel caso in cui la data fosse confermata 
verrà invocato il metodo dateseiectedo , che creerà l'oggetto di tipo userData utilizzando la data 
selezionata, lo renderà persistente attraverso il suo metodo save ( ) e lancerà l'intent per la 
visualizzazione del menu principale dell'applicazione per poi terminare. In questa fase è importante 
notare come non venga più passato l'oggetto userData attraverso un extra come avveniva in 
precedenza. Ora la classe MainActivity avrà la responsabilità di caricare lo userData attraverso il 
metodo ioad ( ) . Nel caso in cui la data non fosse confermata, e venisse invocato il metodo 
selectionCanceled ( ) , non faremo quindi nulla obbligando l'utente alla selezione di una data o di 
un'altra opzione tra login e registrazione. 

Nel caso di login e registrazione visualizziamo le relative activity per poi accedere a due servizi che 
al momento abbiamo solo simulato e che implementeremo invece in modo completo nel prossimo 
capitolo dedicato al multithreading. Dobbiamo pensare a quale possa essere il momento corretto in 
cui creare il profilo e poi salvarlo nelle preferenze. Anche qui molto dipende da quali sono le 
informazioni Nel nostro caso decidiamo di crearlo all'interno del metodo onActivityResult ( ) 
sempre della classe fì rstAccessActivity. Avremmo potuto anche creare e salvare l'oggetto 
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userData all'interno dei servizi stessi, anche se in questo caso avremmo eseguito il codice di 
salvataggio inunthread separato, cosa sempre pericolosa. Il nostro metodo dicallback a seguito 
dell'utilizzo delle attività dilogine registrazione diventa questo: 

dOverride 

protected void onAotivìtyResult (int requestCode, int resultCode, Intent data) { 
if (requestCode == LOGIN_REQUEST_ID) { 
switch (resultCode) { 
case RESULT_OK: 

final UserModel userModel = (UserModel) 

data . getParcelableExtra (LoginActivity . USER_DATA_EXTRA) ; 
userModel . save (this) ; 

final Intent mainlntent = new Intent (this, MenuActivity . class ) ; 
startActivity (mainlntent ) ; 
finish ( ) ; 
break; 
case RESULT_CANCELED: 
break; 

} 

} else if (requestCode == REGISTRATION_REQUEST_ID) { 
switch (resultCode) { 
case RESULT_OK: 

final UserModel userModel = (UserModel) 

data . getParcelableExtra (RegisterActivity . USER_DATA_EXTRA) ; 
userModel . save (this) ; 

final Intent detaillntent = 

new Intent (ShowUserDataActivity . SHOW_USER_ACTION) ; 
startActivity (detaillntent) ; 
break; 
case RESULT_CANCELED : 
break; 

} 

} 

} 

In caso di accesso come anonimo, logjn e registrazione avvenute con successo abbiamo allora il 
salvataggio delle corrispondenti informazioni all'interno delle preferenze. A questo punto il lettore può 
verificare come in mancanza di un profilo si arrivi alla schermata di scelta della modalità di accesso, 
mentre in caso di login, registrazione o accesso anonimo si arrivi direttamente alla schermata relativa 
al menu principale. 

Prima di proseguire dobbiamo però dare la possibilità all'utente di poter effettuare il logout e 
cancellare il proprio profilo. Per farlo aggiungiamo la relativa opzione nella schermata associata a 
MenuActiv ity facendo attenzione che stiamo usando ActionBarSherlock. Le variazioni in questa 
classe sono le seguenti: 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_single_f ragment ) ; 
this .mUserModel = UserModel. load (this) ; 
if (mUserModel == nuli) { 
finish () ; 

} 

if (savedlnstanceState == nuli) { 

final MenuFragment f ragment = new MenuFragment () ; 
getSupportFragmentManager () .beginTransaction () 

. add (R. id. anchor_point, f ragment, MENU_FRAGMENT_TAG) . commit ( ) ; 

} 

} 

SOverride 

public boolean onCreateOptionsMenu (Menu menu) { 

getSupportMenuInf later ( ) . inf late (R . menu . main , menu) ; 

return super . onCreateOptionsMenu (menu) ; 

} 
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@Override 

public boolean onOptionsItemSelected (Menultem itera) { 
switch (item.getltemld () ) { 
case R. id. action_logout : 

mUserModel . logout (this) ; 

final Intent f irstAccessIntent = new Intent (this, 
FirstAccessActivity. class) ; 

startActivity (f irstAccessIntent) ; 

finish ( ) ; 
break; 

case R . id . action_setting : 

final Intent settings Intent = new Intent (this, SettingsActivity. class) ; 
startActivity (settingslntent) ; 

break; 
default : 
break; 

} 

return super . onOptionsItemSelected (itera) ; 

} 

Avendo eliminato la necessità di leggere l'oggetto userModei dall' intent attraverso un opportuno 
extra, notiamo come ora si ottenga il riferimento al modello attraverso il metodo statico ioado . Nel 
caso l'utente non sia loggato, questa attività non ha significato, per cui invochiamo il metodo 
finish ( ) .Vediamo poi la definizione dei metodi relativi alla creazione e gestione delle opzioni del 
menu all'interno del quale è stata aggiunta l'opzione di logout ottenendo il risultato nella Figura 8.2. 
Selezionando l'opzione di logout viene invocato l'omonimo metodo sul modello che provocherà la 
completa cancellazione delle informazioni associate. Di seguito non faremo altro che tornare all'attività 
di iniziale per la scelta dell'opzione di accesso. 
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Figura 8.2 Aggiunta dell'opzione di logout nella barra delle azioni. 

Come il lettore potrà facilmente verificare, oltre a quella di logout esiste un'opzione di setting, la 
quale lancerà un'attività che abbiamo creato e descritto attraverso la classe lettingsActivity, che 
dovrà contenere gli strumenti per la modifica dei dati di configurazione. Essendo una parte importante 
di ogni applicazione, l'SDK mette a disposizione alcune classi che ne semplificano lo sviluppo, come 
descriveremo tra poco. E comunque bene chiarire che al momento si tratta di una parte della 
piattaforma ancora in evoluzione. Da un lato vi sono infatti una serie di metodi deprecati la cui 
alternativa comporterebbe l'utilizzo di classi che non sono invece disponibili nelle versioni della 
piattaforma precedenti TAPI Level 14 e a cui la Compatibility Library non pone rimedio. Per il 
momento siamo quindi costretti a utilizzare dei metodi deprecati ma, in casi come il nostro, in cui si ha 
la necessità di supportare versioni non recentissime della piattaforma, non abbiamo alternative. 

Abbiamo detto che le informazioni che intendiamo editare in questa sezione sono quelle relative ai 
dati inseriti in fase di registrazione oppure ottenuti in fase di logjn. Vogliamo creare un' interfaccia che 
ci consenta di visualizzare, se presente, lo username dell'utente ed editare le informazioni di e-mail, 
data di nascita e location. Per fare questo la piattaforma ci permette di utilizzare un approccio 
dichiarativo attraverso la definizione di un documento XML da passare poi alla nostra attività che 
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dovrà estendere la classe JreferenceActivity, che qui è diventata la classe 

sheriockPreferenceActivity. All'interno di questo file di configurazione, posizionato tra le risorse di 
tipo XML, si può utilizzare una serie di elementi corrispondenti ad altrettanti tipi di informazione, i 
quali dovranno essere contenuti all'interno di un elemento di tipo <PreferenceScreen/>. Alcuni di 
questi elementi, che corrispondono a specifiche specializzazioni della classe Pref erence del package 
android.pref erence, cipermettono l'editing di valori testuali, altri di selezionare un'opzione tra un 
elenco di possibilità e così via. Per tutte le tipologie di componenti rimandiamo alla documentazione 
ufficiale, limitandoci a elencare le principali nella Tabella 8.1. 



Tabella 8.1 Principali tipologie di Preference. 



Tipo di 


Descrizione 


CheckboxPref erence 


Permette la scelta di una o più opzioni tra alcune disponibili. 


DialogPref erence 


Implementazione di base di quelle preferenze che utilizzano una finestra di dialogo. 


EditTextPref erence 


È un tipo particolare di Diaiogpreference che permette l'inserimento di un valore di tipo 
testo. 


ListP ref erence 


Permette la visualizzazione di un insieme di opzioni all'interno di una finestra di 
dialogo. 


SwitchP ref erence 


Dalla versione della piattaforma corrispondente all'API Level 14 è disponibile un 
nuovo componente detto switch e che rappresenta sostanzialmente un interruttore a 
due stati. Questa implementazione di preference consente di utilizzare tale 
componente all'interno di una schermata delle preferenze associandola quindi a un 
valore di configurazione di tipo boolean. Possiamo considerare questo componente 
come la nuova versione di checkBoxPreference. 


RingtonePref erence 


Specializzazione di preference per la selezione della suoneria. 


TwoStatePref erence 


GeneraliZZaziOne di SwìtchPreference e CheckBoxPreference. 



Sono componenti che possiamo comunque aggregare attraverso gli elementi del tipo 
<preferenceGroup/> e <Pref erenceScreen/>. I gruppi ci permettono di aggregare più configurazioni 
sotto una label che ne descrive il tipo. I secondi permettono invece di definire delle etichette 
selezionando le quali è possibile andare a un livello di dettaglio maggiore attraverso una sorta di 
navigazione a livelli. 

Ciascuno degli elementi appnea elencati prevede la definizione di alcuni attributi Alcuni di questi 
sono comuni a tutti gli elementi, mentre altri sono più specifici Quelli di fondamentale importanza sono 
elencati nella Tabella 8.2. 

Oltre a quelli nella tabella vi sono anche altri attributi che consentono la personalizzazione del 
layout, obiettivo che invece noi raggiungeremo attraverso la creazione di un componente disetting 
personalizzato. Nel nostro caso il documento XML di configurazione è il seguente: 

<?xml version="l . 0" encoding="utf-8" ?> 

<Pref erence Screen xmlns : android="http : // schemas . android . com/apk/ res/android"> 
<PreferenceCategory android: title="@string/ setting_horoscope_label"> 
<uk . co .massimocarli . android. ugho . setting . DatePref erence 
android :title="@string/setting_birth_date" 
android: key="birth_date" 

android : widget Layout = " @ layout / sett ing_s ign_image " > 
</uk . co .massimocarli . android. ugho . setting. DatePref erence> 
</PreferenceCategory> 

<Pref erenceCategory 

android : title=" @st ring/ sett ing_registered_user_label " 
android: key="credentìal_category " 

> 

<EdìtTextP ref erence 
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androidi: title="@string/ setting_username " 

androidi : key="uk . co . massimocarli . android . ugho . key . USE RNAME_KE Y " > 
</EditTextPref erence> 
<EditTextPref e r enee 

android :title="@string/ setting_email " 

android: key="uk . co . massimocarli .android . ugho . key . EMAIL_KEY"> 
</EditTextPref erence> 
<EditTextPref erence 

android :title="@string/ setting_locat ion" 

android: key="uk . co . massimocarli .android . ugho . key . LOCATION_KEY"> 
</EditTextPref erence> 
</Pref erenceCategory> 
</Pref erenceScreen> 



Tabella 8.2 Principali attributi. 




android: key 


Si tratta dell'informazione più importante, poiché rappresenta la chiave con cui la 
particolare informazione viene memorizzata all'interno delle sharedPreference. Nella 
nostra applicazione il valore dovrà corrispondere a quello che abbiamo utilizzato 
nella creazione e gestione dello userModei. 


android :defaultValue 


Il significato di questo attributo è banale: è il valore da associare alla chiave 
corrispondente nel caso in cui l'utente non lo editasse in modo esplicito. 


android:title 


Questo attributo contiene la ìabei da visualizzare insieme alla proprietà da editare. 


android: enabled 


Permette di abilitare o meno il particolare elemento di configurazione 


android : dependency 


Questo attributo è molto utile in quanto permette di collegare tra loro più elementi 
di configurazione. È infatti possibile fare in modo che una preferenza venga abilitata 
o meno a seconda del valore di un altro elemento di cui si specifica il valore della 
chiave, e quindi che una serie di componenti vengano abilitati solamente nel caso 
in cui fosse selezionata una casella di controllo o elemento di tipo equivalente. 


android: summary 


Questo attributo è molto utile in quanto permette di visualizzare una descrizione o 
comunque un testo che descrive il valore corrente di opzione di configurazione. 


android : order 


È un attributo che permette di decidere l'ordine con cui i vari elementi di editing 
vengono visualizzati sullo schermo. Si tratta di un'informazione che risulta più utile 
nel caso in cui venisse gestita, in modo dinamico da codice Java, attraverso il 
corrispondente metodo setolerò. 


android: persi stent 


Di default tutte le informazioni relative alle varie preferenze vengono rese persistenti 
e associate alla chiave impostata. Attraverso questo attributo è invece possibile 
fare in modo che alcune di queste informazioni non vengano salvate. Si tratta, per 
esempio, di componenti di supporto come quello che abilita o disabilita una 
sezione della schermata delle preferenze. 


android: selectable 


Questo attributo permette una semplice abilitazione o meno dell'elemento 
corrispondente. 


android : f ragment 


È un attributo che è stato introdotto a partire dall'API Level 11 che permette di 
definire il nome del fragment che verrà visualizzato nel caso in cui l'opzione venisse 
selezionata. Viene usato più che altro nel caso di display grandi in cui si ha 
l'elenco delle sezioni o gruppi nella parte sinistra e i corrispondenti elementi nella 
parte destra. 



Il documento produce come risultato la schermata nella Figura 8.3, che ci accingiamo a descrivere 
nel dettaglio. Come si può osservare nella figura, abbiamo diviso il tutto in due categorie. La prima è 
relativa alle informazioni obbligatorie, mentre la seconda contiene i dati disponibili in caso di accesso 
non anonimo e sarà quindi abilitata solamente in quel caso. Nel nostro esempio abbiamo anche 
approfittato dell'occasione della selezione della data di nascita per descrivere come creare un 
componente di configurazione personalizzata come quello da noi realizzato attraverso la classe 

DatePref erences. 
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Figura 8.3 La nostra schermata delle preferenze. 



Per quello che riguarda invece le informazioni relative a username, e-mail e location abbiamo 
utilizzato degli elementi standard di tipo EditTextPref e r enee. Alla luce di quanto visto, è importante 
notare come le chiavi, associate agli attributi android: key, debbano coincidere con quelle utilizzate 
nella classe userModei in fase di gestione della persistenza. Se riprendiamo la definizione del 
componente personalizzata nel documento XML di configurazione delle preferenze, notiamo come 
come sia stato utilizzato l'attributo android : widgetLayout. Esso ci ha permesso di definire una 
particolare view per la visualizzazione del valore associato alla proprietà di configurazione: 

<uk . co .massimocarli .android . ugno . setting . DatePref e r enee 
android: title="@string/ setting_birth_date" 
android: key="birth_date" 

android : widgetLayout=" @layout/setting_sign_image " > 

</uk . co .massimocarli . android . ugho . setting . DatePref erence> 

Nel nostro caso la view è descritta dal layout setting_sign_image . xml e consente la 
visualizzazione di un'immagine insieme a un'etichetta: 

<LinearLayout xmlns : android="http : / /schemas . android. com/ apk/res/ android" 
android : layout_width="match__parent " 
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androidi : layout_height="match_parent " 
androidi : orientation="vertical"> 

<TextView 

android: layout_width="match_joarent " 
android: layout_height="wrap_content " 
android: id="@+id/setting_horo_sign_label" 

android: textSize=" 18sp" 
android: gravity="center"> 
</TextView> 

<ImageView 

android: layout_width="match_joarent " 
android: layout_height="wrap_oontent " 
android: id="@+id/setting_horo_sign_image" 

android: scaleType="f itCenter" 
android: textColor="@ color /white" 
android : textSize="25sp" 
android : layout_gravity=" center " /> 
</ Linear Layout > 

Il primo elemento di configurazione sarà l'elemento di tipo DatePref erence che abbiamo creato 
estendendo la classe DialogPref erence, che permette l'editing di ima determinata impostazione 
attraverso ima finestra di dialogo. Nel nostro caso volevamo infatti visualizzare la data di nascita 
dell'utente insieme all'immagine e nome del segno zodiacale. Selezionando questo valore volevamo 
poi visualizzare il nostro calendario per la selezione della data. 

NOTA 

In effetti il nostro calendario non permette la selezione dell'anno in modo veloce, per cui la scelta 
della data di nascita è piuttosto noiosa (specialmente per chi ha qualche anno come il sottoscritto). 
Come esercizio il lettore può estendere il nostro componente in modo da consentire la selezione 
dell'anno in modo più rapido. 

I metodi più significativi della nostra classe DatePref erence sono sostanzialmente tre. Il primo è il 
metodo onCreateDialogView ( ) , il quale ha la responsabilità di creare la view che verrà inserita 
all'interno della finestra di dialogo visualizzata quando si seleziona la relativa proprietà: 

@Override 

protected View onCreateDialogView ( ) { 

mCalendarChooser = new CalendarChooser (getContext ( ) ) ; 
mCalendarChooser . setCurrentDate (mSelectedDate) ; 
return mCalendarChooser; 

} 

Possiamo notare come nel nostro caso non si faccia altro che creare un componente di tipo 
CalendarChooser, impostare la data corrente e quindi ritornarlo come valore di ritomo. Questa 
definizione è sufficiente per ottenere il risultato nella Figura 8.4. Una volta creata la finestra di dialogo 
abbiamo bisogno di gestire la selezione della data. Per farlo è sufficiente implementare il seguente 
metodo, che viene invocato quando si preme il pulsante di conferma o di cancellazione: 

HOverrìde 

protected void onDialogClosed (boolean positiveResult ) { 
if (positiveResult) { 

mSelectedDate = mCalendarChooser . getCurrentDate (). getTime () ; 
ìf (mSignlmageView != nuli) { 

final Zodiac zodiac = Zodiac . fromDate (mSelectedDate) ; 
mSignlmageView . set ImageResource (zodiac . get Imageld ( ) ) ; 
mSignTextView. setText (zodiac . toString ( ) ) ; 

} 

callChangeListener (mSelectedDate) ; 

} 

super . onDialogClosed (positiveResult ) ; 

} 
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Figura 8.4 Visualizzazione del calendario alla selezione della data di nascita. 

Il valore del parametro indica se il valore è stato confermato o meno. In caso positivo non 
tacciamo altro che leggere la data e, attraverso lina classe di utilità che si chiama zodiac, calcolare il 
segno zodiacale e poi la corrispondente immagine. Da notare l'invocazione del metodo 
caiichangeListener ( ) per la notifica agli eventuali listener del metodo di modifica del dato, come 
vedremo nella s ettingsActivity. L'ultimo passo è poi quello relativo alla gestione della view 
impostata attraverso l'attributo android: widget Layout. Per fere questo utilizziamo il seguente metodo 
di callback, che viene invocato proprio in corrispondenza della creazione della view che dovrà poi 
renderizzare la riga nei setting: 

HOverrìde 

protected View onCreateView (ViewGroup parent) { 

View settingsView = super . onCreateView (parent) ; 
mSignlmageView = (ImageView) 
settingsView. f indViewByld (R. id. setting_horo_sign_image) ; 

mSignTextView = (TextView) settingsView. findViewByld (R. id. setting_horo_sign_label) ; 
if (mSignlmageView != nuli) { 

final Zodiac zodiao = Zodiac . fromDate (mSelectedDate) ; 
mSignlmageView . set ImageResource ( zodiac . getlmageld ( ) ) ; 
mSignTextView . setText ( zodiac . toString ( ) ) ; 



328 



} 

return settingsView; 

} 

Vediamo infatti come si ottengano i riferimenti all'imageview e Textview che poi si andranno a 
valorizzare rispettivamente con l'immagine del segno zodiacale e il nome relativo. 

La nostra settingsActivity avrà la responsabilità di gestire gli eventi relativi alla selezione della 
data di nascita e di visualizzare i campi di riepilogo: 

public class SettingsActivity extends SherlockPref erenceActìvity { 

private static final DateFormat BIRTH_DATE_FORMAT = 

new SimpleDateFormat ( "dd MMMM yyyy"); 

private UserModel mUserModel; 

private Pref erence . OnPref erenceChangeListener mListener = new 
Pref e r enee . OnPref erenceChangeListener ( ) { 
@Override 

public boolean onPref erenceChange (Pref erence preference, Object o) { 
ìf (preference == mBirthDatePref erence) { 
mUserModel . setBirthDate (mBirthDatePref erence . getSelectedDate ( ) . getTime ( ) ) ; 
mUserModel . save (getApplicatìonContext ( ) ) ; 

} 

updatelnf o ( ) ; 
return true; 

} 

}; 

private Preference mCredentialCategory; 

private DatePref erence mBirthDatePref erence; 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
addPref erencesFromResource (R.xml . setting) ; 
mUserModel = UserModel . load (this ) ; 

mBirthDatePref erence = (DatePref erence) findPref erence ( "birth_date" ) ; 
mBirthDatePref erence . setSelectedDate (mUserModel . getBirthDate ( ) ) ; 
mBirthDatePref erence . setOnPref erenceChangeListener (mListener) ; 
mCredentialCategory = findPref erence ( "credential_category ") ; 
mCredentialCategory . setOnPref erenceChangeListener (mListener) ; 

} 

SOverride 

protected void onResume ( ) { 
super . onResume ( ) ; 
updatelnf o ( ) ; 

} 

private void updatelnfoO { 

final UserModel userModel = UserModel. load (this) ; 
if (TextUtils . isEmpty (userModel . getUsername ( ) ) ) { 

f indPref erence ("credential_category") . setEnabled (false) ; 
} else { 

f indPref erence ("credential_category") .setEnabled (true) ; 

findPref erence ( "uk . co .massimocarli . android. ugho . key .USERNAME_KEY" ) 

. setSummary (userModel . getUsername ( ) ) ; 
findPref erence ( "uk . co .massimocarli . android. ugho . key . EMAIL_KEY" ) 

. setSummary (userModel . getEmail ( ) ) ; 
findPref erence ( "uk . co .massimocarli . android. ugho . key . LOCATION_KEY" ) 

. setSummary (userModel . getLocation ( ) ) ; 

} 

final Date birthDate = new DateO; 

birthDate . setTime (mUserModel . getBirthDate ( ) ) ; 

mBirthDatePref erence . setSummary (BIRTH_DATE_FORMAT . format (birthDate) ) ; 

} 
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} 

Nel frammento di codice evidenziato abbiamo quindi abilitato o disabilitato la categoria associata ai 
dati di registrazione nel caso in cui fossero presenti 

La gestione dei file 

Come accennato nella parte introduttiva di questo capitolo, Android utilizza la maggior parte degli 
strumenti di gestione dei file ofièrti dalla piattaforma standard Java. Anche in questo caso abbiamo la 
possibilità di utilizzare tutte le diverse implementazioni di inputstream, outputstream, Reader e 
writer, oltre che le classi relative a quello che si chiama NIO (New I/O) e che permettono una 
gestione a buffer. In questa sede tratteremo solamente quegli strumenti che sono tipici della 
piattaforma Android e in particolar modo: 

• leggere e scrivere sul file system locale; 

• leggere e scrivere su CD card; 

• leggere da un file statico all'interno di un'applicazione. 

Tratteremo questi argomenti in modo abbastanza veloce in quanto si tratta di strumenti che le API 
specifiche di Android in qualche modo mascherano mettendoci a disposizione API di più alto livello. 

Accesso a file system locale 

Gli strumenti forniti per l'accesso ai file sono, come detto, gli stessi ofièrti da Java standard, ovvero 
gli stream Da un'activity, è possibile ottenere il riferimento agli stream di lettura e scrittura a un file 
attraverso i seguenti metodi che la stessa eredita dalla classe context: 

public abstract FilelnputStream openFilelnput (String name) 

public abstract FileOutputStream openFileOutput (String name, int mode) 

specificando il nome del file e, nel caso della scrittura, anche il mode che, a seconda del valore, 
permette di deciderne la visibilità da parte delle altre applicazioni Un valore corrispondente alla 
costante mode_private della classe context, che è il default, consente di specificare che il file è 
accessibile solamente alla sola applicazione che lo ha creato. Il valore corrispondente alle costanti 
mode_world_readable permette di dare alle altre applicazioni la possibilità di accedere in lettura. Per 
assegnare il permesso di scrittura si può utilizzare la costante mode_world_writeable. Oltre a questi 
valori, già incontrati nel caso delle sharedPreferences, esiste quello associato alla costante 
mode_append, che consente, in fase di scrittura, di appendere informazioni al file nel caso in questo sia 
già esistente invece che sovrascriverlo completamente. 

NOTA 

Come sappiamo, dalla versione 1.4 di Java, oltre a una gestione attraverso il concetto di stream, è 
stata aggiunta la possibilità di lavorare attraverso dei buffer. Attraverso quelli che sono stati chiamati 
Java NIO ( New I/O) si possono infatti leggere e scrivere in modo più efficiente informazioni da e 
verso fonti dati. Android dispone di queste API, le quali sono contenute all'interno di package del 
tipo java.nio ma che non saranno argomento del presente libro. 

Come esempio di utilizzo di queste API vogliamo realizzare una piccola funzione all'interno delle 
nostre impostazioni che ci consenta di leggere le informazioni relative alle preferenze salvate su file e 
quindi visualizzarle all'interno di una finestra di dialogo. Prima di procedere andiamo a vedere dove 
queste informazioni sono state salvate. Entriamo allora in Android Studio e visualizziamo uno 
strumento che si chiama DDMS (Dalvik Debug Monitor Service) attraverso la relativa opzione nel 
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menu nella Figura 8.5, ottenendo la finestra nella Figura 8.6. La stessa opzione è accessibile 
attraverso la selezione dell'icona di Android nella barra degli strumenti. È uno strumento che ci 
permette di interagire in modi diversi con il dispositivo. Nel nostro caso abbiamo bisogno di accedere 
al file system, per cui utilizziamo un AVE) in quanto il dispositivo (a meno che non sia stato "rootato") 
non ci consente l'accesso ai diversi file. 
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Figura 8.5 Avviamo il tool DDMS attraverso la relativa opzione nel menu Tools. 
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Figura 8.6 II tool DDMS in esecuzione. 
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Inizialmente il DDMS ci mostrerà nella parte sinistra un elenco dei processi in esecuzione tra cui (se 
installato e in esecuzione) anche quello della nostra applicazione (nella Figura 8. 6 il processo non è 
presente). 

Installiamo ora la nostra applicazione eseguendola nell'AVD creato; noteremo il processo della 
nostra applicazione tra quelli in esecuzione, come mostrato nella Figura 8.7 in fondo alla lista. 
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Figura 8.7 II processo dell'applicazione aggiunto all'elenco. 



Selezioniamo la voce Show View nel menu Window, ottenendo la finestra nella Figura 8.8, in cui 
andremo a scegliere la specifica finestra da inserire all'interno deltooL Come mostrato nella figura 
apriamo il gruppo relativo ad Android e selezioniamo File Explorer. 
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Figura 8.8 Aggiungiamo File Explorer. 



Come possiamo notare dalla Figura 8.9, in questa nuova vista viene visualizzato il file system del 
nostro dispositivo. 
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Figura 8.9 La root del file system del nostro emulatore. 



Prima di proseguire diciamo subito che con il comando adb {Android Debug Bridge) è possibile 
accedere all'emulatore attraverso una shelL Per fare questo è sufficiente il comando 

adb -s emulator-5554 shell 

dove l'opzione s non sarebbe necessaria nel caso in cui fosse attivo un unico dispositivo o 
emulatore. All'interno del file system, che ci ricorda (non a caso) molto da vicino quello di un sistema 
Linux, possiamo notare la presenza del percorso /data/data, che contiene l'elenco di tutte le 
applicazioni installate nel dispositivo, come mostrato nella Figura 8.10. 
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Figura 8.10 In /data/data vi sono le cartelle associate alle applicazioni installate. 
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Tra le cartelle in data/data noteremo quella associata alla nostra applicazione, la quale sarà 
inizialmente vuota. Dopo l'esecuzione e la creazione di un profilo vedremo invece la struttura nella 
Figura 8.11. 
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Figura 8.11 Creazione del file dei setting. 



Come possiamo notare è stata creata una cartella di nome shared _prefs, che contiene un file XML 
di nome legato al package dell'applicazione. Si tratta del file che abbiamo utilizzato per i setting, il 
quale avrebbe avuto nome diverso nel caso in cui non avessimo utilizzato Pref erenceManager. Come 
esercizio di utilizzo dei file vogliamo aggiungere un'opzione ai nostri Settings per la visualizzazione di 
questo file all'interno di una finestra di dialogo. Dopo il lavoro latto per la gestione del calendario 
sappiamo ormai come fare. Abbiamo così creato la classe showPreference, il cui metodo principale è 
quello di creazione della view, ovvero onCreateDiaiogviewo : 

HOverrìde 

protected View onCreateDialogView ( ) { 

final Layoutlnf later inflater = Layoutlnf later . f rom (getContext ( ) ) ; 

final View textContainer = inflater . inf late (R. layout . setting_show_f ile, nuli); 

final TextView settingsTextView = (TextView) 

textContainer . f indViewByld (R. id . setting_show_f ile) ; 
PackageManager packageManager = getContext (). getPackageManager () ; 
String applicationPackage = getContext (). getPackageName () ; 
String applicationPath = nuli; 
try { 

Packagelnfo packagelnfo = packageManager. getPackagelnfo (applicationPackage, 0); 
applicationPath = packagelnfo. applicationlnfo.dataDir; 
} catch (PackageManager .NameNotFoundException e) { 
e . printStackTrace ( ) ; 

} 

FilelnputStream settingsInputStream = nuli; 
try { 

ByteArrayOutputStream baos = new ByteArrayOutputStream() ; 
File prefsFile = new File (applicationPath, PREFS_FILE_PATH) ; 
settingsInputStream = new FilelnputStream (pref sFile) ; 

byte[] buffer = new byte [BUFFER_SIZE] ; 
int bytesRead = 0; 

while ((bytesRead = settingsInputStream. read (buffer, 0, buf f er . length) ) > 0) { 
baos . write (buffer, 0, bytesRead); 

} 

final byte[] prefsAsBytes = baos . toByteArray ( ) ; 
final String textToShow = new String (pref sAsBytes) ; 
baos . dose ( ) ; 

settingsTextView . setText (textToShow) ; 
} catch (IOException e) { 
e . printStackTrace ( ) ; 

settingsTextView . setText ( "Error : " + e . getCause ( ) ) ; 
} finally { 

if (settingsInputStream != nuli) { 
try { 

settingsInputStream. dose ( ) ; 
} catch (IOException e) { 
e . printStackTrace ( ) ; 
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} 

} 

} 

return textContainer ; 

} 

Il lettore potrebbe obiettare sul fatto che non siano stati utilizzati i metodi di Context descritti in 
precedenza. Questo perché si tratta di metodi che vogliono come parametro un percorso che non 
contiene separatori di cartella e che quindi sono relativi alla root dell'applicazione. Per questo motivo 
abbiamo invece ottenuto il percorso dall'oggetto responsabile della gestione di tutte le applicazioni, 
ovvero il PackageManager. Da notare come il layout sia stato ottenuto attraverso l'inflette dal seguente 

documento setting_show_file.xmi: 
<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<ScrollView xmlns : android="http : / / schema s . android. com/ apk/ res/ android" 
android : layout_width="match_parent " 
android : layout_height="match__parent " 
android : orientation="vertical"> 
<TextView 

android: layout_width="match_parent " 
android : layout_height="match_parent " 
android: id="@+id/ setting_show_f ile" 
android : textSize=" 18sp" 
android : gravity= " center "> 
</TextView> 
</ScrollView> 

Il componente è stato definito nelle preferenze attraverso questo frammento: 

<Pref erenceCategory android : title="@string/ setting_others"> 
<uk . co .massimocarli . android. ugho . setting . ShowPref erence 
android : title=" @st ring/ set ting_as_text " 
android: per si stent=" f alse"> 
</uk . co . massimocarli . android . ugho .setting . ShowPref erence> 
</Pref erenceCategory> 

ottenendo come risultato quello nella Figura 8.12. 
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j É 10:41 



Settings as Text 



<?xml version='1.0' encoding='utf-8' 
standalone='yes' ?> 
<map> 
<long 

|name="uk.co.massimocarli.android.ugho| 
.key.BIRTHDATE_KEY" 
value="l 37500221 8957" /> 
<string 

|name="uk.co.massimocarli.android.ugho| 
key.EMAIL_KEY">maxcarli@max.com</ 
string> 
<string 

|name="uk.co.massimocarli.android.ugho| 
.key.USERNAME_KEY">maxcarli</string>! 
<string 

|name="uk.co.massimocarli.android.ugho| 
.key.LOCATION_KEY">London</string> 
</map> 



Cancel 



OK 



Figura 8.12 II contenuto del documento XML con i dati delle impostazioni. 



Come vedremo di volta in volta, il Context ci permetterà di accedere a diverse directory 
specifiche dell'applicazione corrente come quella che conterrà iDB 

public abstract File getDatabasePath (String name) 

o quella per la memorizzazione delle informazioni di cache 

public abstract File getCacheDir ( ) 



File su SD Card 

Come sappiamo, la maggior parte dei dispositivi è dotata di una memoria esterna, che viene spesso 
indicata con il termine SD Card. Sono memorie che ormai hanno raggiunto dimensioni fino a 32 GB 
che possono essere aggiunte o tolte dal dispositivo attraverso l'apposito slot. 

NOTA 

Il nome SD Card deriva da Secure Digital e rappresenta un modo veloce per descrivere dei chip di 
memoria flash utilizzati non solo nei telefoni cellulari ma soprattutto in dispositivi come le macchine 
fotografiche 
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Il procedimento di lettura e scrittura di file dalla SD Card non è molto diverso da quanto visto nel 
paragrafo precedente. La sola differenza sta nella directory in cui tali memorie vengono "montate", 
termine con cui si indica che la memoria è visibile al dispositivo come se fosse una cartella all'interno 
del file system Qui la cartella dedicata alla SD Card si chiama /s dcard ed è presente all'interno della 
root del dispositivo. Nel caso in cui non si disponesse di un device reale, possiamo simulare la 
presenza della SD Card attraverso l'emulatore. Se non già fatto, dovremo inserire un valore nel 
campo SD Card in fase di creazione dell'AVD come nella Figura 8.13. 
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Figura 8.13 Impostazione relativa alla dimensione delI'SD Card nella creazione dell'AVD. 

Nel nostro caso abbiamo impostato ma dimensione dell' SDK Card di 1 GB. E consigliabile non 
superare tale valore nell'AVD al fine di non allocare troppo spazio su disco o di rallentare l'avvio 
dell'emulatore. 

Un modo alternativo di creazione dell' SD Card è quello di utilizzare il tool 

mksdcard 

presente nella cartella tools di installazione dell'ambiente Andro id, specificando la dimensione e il 
nome del file relativo all'immagine creata. Se volessimo creare l'immagine della stessa SD Card 
definita attraverso l'AVD, basterebbe eseguire questo comando: 

mksdcard 1024M sdcard.img 

dove il secondo parametro indica il nome del file a cui si potrà poi fare riferimento nel tool 
precedente per la definizione della memoria esterna. Il file che viene creato in questo modo può anche 
essere installato nell'emulatore attraverso il comando emuiator: 

emulator -sdcard sdcard.img 

Facendo partire l'emulatore e osservando il relativo file system attraverso iltoolF?7e Explorer 
vediamo come sia possibile inserire dei file nella cartella /sdcard attraverso gli strumenti del tool 
stesso oppure attraverso il comando adb. Si può infatti inserire un file dalla nostra macchina al 
dispositivo attraverso il comando 

adb push <local file> <file device> 

e viceversa dal dispositivo al nostro PC attraverso il comando 

adb pulì <file device> <local file> 

Nel caso della SD Card non realizzeremo alcun esempio, in quanto si tratta dello stesso 
meccanismo mostrato nel paragrafo precedente in relazione al file delle preferenze. Nonostante 
questo ci sono però due importanti considerazioni da fare. La prima riguarda la modalità con cui è 
possibile ottenere il percorso associato, ovvero attraverso il seguente codice: 

File sdcardDir = Environment . getExternalStorageDirectory ( ) ; 
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File file = new File (sdcardDir, FILE_PATH) ; 

La seconda riguarda invece la necessità di definire, all'interno del file AndroidManif est . xml, li 
corrispondente permesso attraverso la seguente definizione: 

<uses-permission android: name="android.permission . WRITE_EXTERNAL_STORAGE"></ uses- 
permission> 

Come altre operazioni che possono in qualche modo essere dannose, in quanto accedono a 
informazioni sensibili e possono portare a dei costi, devono essere dichiarate nel file di configurazione. 
Queste informazioni vengono visualizzate in fase di installazione e possono quindi indurre l'utente a 
rifiutare l'applicazione. 

Come sappiamo sia il codice sia le risorse associate a un'applicazione Android sono contenuti 
all'interno di un pacchetto apk. Nel caso in cui si intendesse inserire al suo interno dei file a cui 
accedere attraverso una particolare costante della classe r ma senza applicare a essi alcun processo 
di ottimizzazione, è sufficiente inserirli nella cartella /res/raw. Il caso più tipico è quello di alcuni file, 
magari XML, di configurazione a cui l'applicazione ha la necessità di accedere solamente in lettura. 
Per accedere a queste risorse è sufficiente utilizzare il metodo 

public InputStream openRawResource (int id) 

della classe Resources di cui otteniamo, un'istanza attraverso il metodo getResources o visibile 
all'interno diun'activity. Una volta ottenuto il riferimento all'inputstream possiamo leggere ed 
eventualmente elaborare il file corrispondente. 

SQLite 

Una delle caratteristiche più importanti di Android nella gestione dei dati riguarda la disponibilità di 
un DB relazionale. Si tratta di SQLite (http : / /www . sqiite . org/ ) , ovvero di un DBMS che ha tra le 
sue caratteristiche principali quelle di essere molto piccolo (intorno ai 500 KB), molto veloce, 
semplice e portabile e quindi adatto a dispositivi con risorse limitate. Essendo uno strumento utilizzato 
anche in altri ambienti, si può usufruire di un buon numero di tool per la creazione e gestione dei 
database. In Android gli strumenti per la gestione di SQLite si possono suddividere in due parti, 
ciascuna corrispondente a uno dei seguenti package: 

• android . database; 

• android . database . sqlite. 

Il primo contiene una serie di classi per la gestione dei classici cursori verso un insieme di record 
provenienti da una base dati generica. E un insieme di implementazioni dell'interfaccia cursor che, 
unite ad alcune classi di utilità, permettono una gestione semplificata delle informazioni persistenti II 
secondo package contiene invece classi più specifiche per la gestione delle informazioni attraverso 
SQLite. In questa parte vedremo come utilizzare un DB SQLite per la memorizzazione delle 
informazioni locali relative alle nostre famose valutazioni. Approfitteremo poi del nostro caso per 
descrivere argomenti di carattere generale che potrebbero comunque essere utili in altre applicazioni. 

Il ciclo di vita di un database SQLite 

Come già accennato, Android ci consente di creare dei DB SQLite che dal punto di vita pratico 
non sono altro che dei file che possono essere copiati, rimossi o spostati come un qualunque altro. 
Come ogni altro file, potrà quindi essere privato di una sola applicazione (scelta di default e 
consigliata), oppure condiviso tra più applicazioni e processi. A ognuno di questi la piattaforma 
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associa un oggetto di tipo SQLiteDatabase, il quale rappresenta la vera interfaccia a nostra 
disposizione sia per l'interazione con i dati sia per la creazione, l'aggiornamento e la cancellazione del 
DB associato. 

Per creare un DB SQLite associato a un'applicazione è possibile utilizzare il seguente metodo 

Statico della classe SQLiteDatabase: 

public static SQLiteDatabase openDatabase (String path, 

SQLiteDatabase . CursorFactory factory, int flags) 

Il parametro path indica il nome del file, con estensione . db, che conterrà il database il cui nome 
viene creato attraverso questa convenzione: 

/data/data/<nome package applicazione>/database/<path> . db 

e che sarà unico all'interno della stessa applicazione, che potrà comunque contenere anche DB 
diversi. 
NOTA 

Database di applicazioni diverse vengono creati in directory diverse e quindi possono anche avere lo 
stesso nome. 

Il secondo parametro è un riferimento a un'implementazione dell'interfaccia 
SQLiteDatabase. CursorFactory che è responsabile della creazione della particolare implementazione 
di cursor che andremo a utilizzare per l'accesso ai risultati delle varie query. Si tratta di un parametro 
opzionale a cui spesso si associa il valore nuli, che corrisponde all'utilizzo dell'implementazione di 
default. Come vedremo successivamente, cursor è l'interfaccia che descrive gli strumenti da utilizzare 
per estrarre le informazioni dal risultato di una query. L'implementazione fornita di default è descritta 
dalla classe SQLiteCursor. Nel caso in cui volessimo invece aggiungere alcune funzionalità a tale 
implementazione potrebbe essere utile creare una specializzazione di questa classe da utilizzare al 
posto di quella di default. È il caso tipico di implementazione dell'interfaccia 
SQLiteDatabase. CursorFactory, che prevede la definizione della seguente operazione: 

public abstract Cursor newCursor (SQLiteDatabase db, 

SQLiteCursorDriver masterQuery, String editTable, SQLiteQuery query) 

dove db è il riferimento al database, editTable è la tabella a cui si riferisce la query che dovrà 
produrre ilcursor e query è un oggetto di tipo SQLiteQuery che incapsula le informazioni relative alla 

query eseguita. Il Secondo parametro di nome masterQuery è di tipo SQLiteCursorDriver e 

rappresenta gli oggetti responsabili della creazione deicursor e del loro ciclo di vita. Sebbene si tratti 
di una funzionalità considerata spesso come evoluta, è usata spesso in particolari tipi di applicazioni 
Di seguito ne daremo anche una nostra implementazione. 

Molto importante è poi il parametro f ìags, con cui specificare la modalità di accesso al DB aperto 
o creato. Attraverso il flag descritto dalla costante create_if_necessary si può specificare se creare 
il database prima di aprirlo nel caso in cui non esistesse. Questo permette di creare il database, per 
esempio, alla prima esecuzione di un' applicazione e di aprirlo solamente nelle esecuzioni successive. 
Attraverso la costante open_readonly si può aprire il DB solamente in lettura, a differenza che con il 
valore open_readwrite, che consente invece di accedere anche in scrittura. L'ultima opzione è 
associata alla costante no_localized_collators, che permette di non utilizzare i collator associati a 
una data lingua nei confronti fra contenuti testuali 

NOTA 

Come sappiamo, ordinare o semplicemente confrontare due testi è un'operazione che dipende dalla 
particolare lingua utilizzata. Se pensiamo, per esempio, ai caratteri presenti nella lingua tedesca o 
spagnola oppure in alcune lingue orientali capiamo come sia utile poter gestire diverse modalità a 
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seconda del particolare Locale. Android sfrutta una caratteristica di SQLite che si chiama collection 
e che consente appunto di far dipendere dal Locale i criteri di confronto e ordinamento delle 
informazioni testuali. Attraverso la costante NO_LOCALI ZED_COLLATORS si intende specificare come le 
funzionalità di ricerca testuali non dipendano dal Locale e quindi non vengano influenzate 
dall'esecuzione del metodo setLocaieo. 

Abbiamo visto che la creazione di un DB si traduce nella creazione di un file con estensione . db. 
Nel caso in cui si intendessero sfruttare le caratteristiche relazionali di un DB per l'accesso a 
informazioni in modo efficiente, si può creare un database in memoria senza quindi la creazione del file 
corrispondente. Per farlo è sufficiente utilizzare il metodo 

public static SQLiteDatabase create (SQLiteDatabase . CursorFactory factory) 

Si tratta di un metodo per la creazione di un DB nuovo e non per l'apertura di qualcosa di 
esistente; per sua stessa natura verrà completamente eliminato al momento della chiusura. Anche 
questo metodo prevede la definizione di un'implementazione di SQLiteDatabase. CursorFactory per 
la quale valgono le stesse considerazioni fatte sopra. 

Una proprietà molto importante di un DB è la versione corrispondente. È semplicemente un valore 
di tipo intero associato a un database che permette, per esempio, di decidere se apportare 
determinate modifiche nel caso di aggiornamenti all'applicazione che lo ha definito. L'accesso a 
questa informazione è possibile attraverso il metodo 

public int getVersion() 

mentre si può verificare se esiste la necessità o meno di un aggiornamento attraverso l'invocazione 
del seguente metodo di utilità 

public boolean needUpgrade (int newVersion) 

a cui è sufficiente passare l'identificatore della eventuale nuova versione disponibile ottenendo in 
risposta il corrispondete valore booleano. Nel caso, sarà responsabilità del programmatore eseguire 
le opportune query di aggiornamento dei dati o dello schema conseguenti alla modifica di versione. La 
cancellazione di un database esistente offre diverse possibilità. La più complessa consiste nella 
cancellazione del file corrispondente, mentre la modalità più semplice è quella che prevede 
l'invocazione del seguente metodo che la classe Activity eredita dalla classe ContextWrapperl 

public boolean deleteDatabase (String name) 

Il parametro indica il nome del DB, mentre il valore di ritomo indica se l'operazione di 
cancellazione è avvenuta con successo o meno. Altra opzione è l'esecuzione di un'istruzione di drop 
attraverso le API di esecuzione delle query che vedremo più avanti 

È interessante osservare come la stessa classe contextwrapper metta a disposizione di ogni activity 
anche altri metodi di utilità per la gestione di un database. Se si volessero, per esempio, elencare i 
database privati disponibili per una particolare applicazione sarà sufficiente invocare il metodo 

public String [] databaseList ( ) 

mentre per conoscere il percorso esatto del file associato, il metodo da utilizzare è il seguente: 

public File getDatabasePath (String name) 

La classe Activity eredita poi anche il metodo 

public SQLiteDatabase openOrCreateDatabase (String name, int mode, 

SQLiteDatabase . CursorFactory factory) 

con funzionalità leggermente diverse rispetto a quelle viste per la classe SQLiteDatabase. Come nel 
caso precedente di utilizzo delflag create_if_necessary, il DB viene aperto dopo essere stato 
eventualmente creato nel caso in cui non esistesse. Il parametro mode ha poi un significato diverso 
rispetto ai flag precedenti e permette di specificare la visibilità del file corrispondente attraverso le 
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costanti della classe context viste in occasione della gestione dei file. 

Infine, una volta che il database è stato utilizzato, lo si deve chiudere invocando sull'oggetto 

SQLiteDatabase ilmetodo: 
public void dose () 

Quelli descritti sono gli strumenti che la classe SQLiteDatabase ci offre per la gestione di un 
database SQLite. Di seguito vedremo dei metodi alternativi, più integrati nella piattaforma, che ci 
consentiranno di gestire il tutto in modo più ottimizzato. 

Come dimostrazione di questo approccio nella creazione del DB abbiamo creato la classe dao, la 
quale ci permetterà appunto di eseguire le operazioni di gestione della persistenza. Come il lettore 
potrà osservare nel relativo codice, per quello che riguarda la creazione del DB abbiamo 
implementato questo metodo: 

public static synchronized DAO get (final Context context) { 
return new DAO (context . getApplicationContext ()) ; 

} 

public void open ( ) { 

if (mDb == nuli || ! mDb . isOpen ( ) ) { 

final File dbFile = mContext.getDatabasePath(DB_NAME) ; 

final boolean wasExisting = dbFile .exists () ; 

mDb = mContext . openOrCreateDatabase (DB_NAME, Context .MODE_PRIVATE, nuli); 

if (! wasExisting) { 

// Inizializzazione del DB 

Log . d (TAG_LOG, "The DB is new so we initialise it!"); 
} else { 

Log . d (TAG_LOG, "The DB is already initialised ! " ) ; 

} 

} 

} 

Attraverso il riferimento al Context passato al metodo statico di Factory get ( ) , otteniamo il 
riferimento al file che dovrebbe contenere il nostro DB e ne verifichiamo l'esistenza. Questo 
accorgimento si rende necessario inquanto ilmetodo openOrCreateDatabase o non ci dice se il DB 
era già esistente oppure no. L'informazione serve per la creazione dello schema del DB che vedremo 
nel prossimo paragrafo. Concludiamo questa parte sottolineando come il nostro DAO debba 
comunque implementare una sorta di ciclo di vita, in quanto la connessione al DB andrà aperta ma 
dovrà anche essere chiusa. Per farlo avremo bisogno di legare il ciclo di vita del DAO a quello del 
componete che lo conterrà: nella maggior parte dei casi un'activity o un fragment. 

Creazione delle tabelle 

Quando il DB viene creato è vuoto, per cui il passo successivo consisterà nella creazione dello 
schema, ovvero dell'insieme delle tabelle, indici, viste e altri elementi tipici di un database relazionale. 
NOTA 

Il lettore potrà fare riferimento alla versione di SQL utilizzata da SQLite sul sito ufficiale all'indirizzo 

http : / /www . sqlite . org. 

Come abbiamo già accennato, noi utilizzeremo il DB per l'inserimento delle informazioni relative ai 
diversi stati d'animo per i vari giorni dell'anno. Per fare questo abbiamo già creato il modello 
corrispondente attraverso la classe LocalDataMode i, che dispone delle seguenti proprietà: 

• id 

• entryDate 

• loveVote 
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healthVote 

workVote 

luckVote 



Sono tutti valori numerici che dovranno corrispondere ad altrettante colonne nella tabella che 
chiamiamo horo_vote. Un aspetto importante dei DB in ambiente Android riguarda la chiave id. 
Infatti, come vedremo successivamente quando tratteremo i content provider, è sempre bene utilizzare 
come identificatore una colonna di nome _id. 

NOTA 

Si tratta solo di una convenzione che è comunque bene seguire in quanto diversi strumenti offerti 
dalla piattaforma si basano proprio su una colonna con questo nome. 

Il nostro script per la creazione della tabella sarà il seguente: 

CREATE TABLE HORO_VOTE ( 

_id integer PRIMARY KEY AUTOINCREMENT UNIQUE, 

entry_date date NOT NULL UNIQUE, 

love_vote integer NOT NULL, 

health_vote integer NOT NULL, 

work_vote integer NOT NULL, 

luck_vote integer NOT NULL, 

horo_sign text NOT NULL) ; 
CREATE INDEX UNIQUE_ENTRY_DATE ON HORO_VOTE (_id, entry_date) ; 

Vediamo come l'identificatore sia stato utilizzato il nome _id per la chiave e come sia stata aggiunta 
una colonna di nome horo_sign per il nome del segno zodiacale a cui i dati fanno riferimento. 
NOTA 

Nel nostro caso si tratta di un'informazione che abbiamo aggiunto per avere un tipo di dato testuale 
nella tabella, ma sarà comunque utile quando dovremo trasmettere i dati al server. Facciamo inoltre 
attenzione che i nomi delle colonne sono case sensitive. 

A questo punto abbiamo da un lato la necessità di inserire questo script nell'applicazione e 
dall'altro di eseguirlo per la creazione dello schema al primo utilizzo. Per quello che riguarda la 
memorizzazione dello script decidiamo di inserirlo come risorsa di tipo raw, che sappiamo essere 
quel tipo di risorsa per la quale viene definita ima costante della classe r ma a cui il sistema non 
applica alcun meccanismo di ottimizzazione, come può invece avvenire per le altre tipologie di risorse. 
Creiamo quindi la cartella raw all'interno della cartella res delle risorse e inseriamo il testo precedente 
all'interno del file create_schema.sqi come nella Figura 8.14. 

Per semplificarne la lettura abbiamo creato una classe di utilità che abbiamo chiamato 
Resourceutiis, tra i cui metodi vi è quello di nome getRawAsstring ( ) per la lettura appunto di un 
testo contenuto all'interno di una risorsa di tipo raw. 

NOTA 

Resourceutiis è una classe di utilità che, insieme alla classe ioutus, permette di leggere alcune 
informazioni di tipo String da fonti diverse. Consigliamo al lettore di consultare il relativo codice 
come esercizio della gestione dei file e dell'accesso alle risorse di Android. 
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Figura 8.14 Creazione della risorsa di tipo raw per lo script di creazione dello schema. 

Una volta ottenuto lo script di creazione dello schema dobbiamo poterlo eseguire. Per fare questo 
ci sono diverse possibilità tra cui l'utilizzo di un metodo di nome execSQL ( ) , che vedremo nel 
prossimo paragrafo e che consente appunto l'esecuzione di script SQL generici In questa occasione 
decidiamo invece di utilizzare un metodo della classe Databaseutiisii, che però si occupa anche 
della creazione del DB introducendo il concetto di versione che prima era assente: 

public static void createDbFromSqlStatements (Context context, String dbName, 

int dbVersion, String sqlStatements ) 

Questo ci porta alla modifica del precedente metodo di apertura del DB, che ora diventa un po' 
più complicato: 

public void open ( ) { 

if (mDb == nuli || ! mDb . isOpen ( ) ) { 

final File dbFile = mContext . getDatabasePath (DB_NAME) ; 
final boolean wasExisting = dbFile . exìsts () ; 
if (! wasExisting) { 

final String createDbStatement ; 
try { 

createDbStatement = ResourceUtils 

. getRawAsString (mContext , R . raw . create_schema) ; 
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DatabaseUtils . createDbFromSqlStatements (mContext , 
DB_NAME, DBJVERSION, createDbStatement) ; 

} catch (IOException e) { 
e . printStackTrace ( ) ; 

} 

} 

mDb = mContext . openOrCreateDatabase (DBJNAME, Context . MODE_PRIVATE , nuli); 

int oldVersion = mDb . getVersion ( ) ; 
if (oldVersion != DBJVERSION) { 

// In questo caso dovremo gestire la diversa versione del DB 

} 

} 

} 

All'inizio, come nel caso precedente, verifichiamo se il DB è già presente oppure no. Nel caso in 
cui non fosse presente lo creiamo con il metodo di utilità visto. In ogni caso questo metodo comunque 
non apre il DB, per cui si rende necessaria l'esecuzione del metodo openOrCreateDatabase ( ) , ma 
dovrebbe solo aprire il DB esistente a meno di eventuali eccezioni. Infine vi è, solo accennata, una 
parte digestione delle diverse versioni di DB. Se infatti il valore della costante db_version è diverso 
dalla versione del DB installata in quel momento, si ricade nel caso in cui una nuova versione 
dell'applicazione ha aggiornato anche il proprio DB. Nella parte di codice evidenziata vi dovrà anche 
essere l'eventuale gestione di una versione diversa del DB. Come vedremo successivamente, se idati 
lo permettono, questa gestione consiste nella completa cancellazione del DB esistente e nella 
creazione di un nuovo DB. Se idati sono invece sensibili e non possono essere scaricati su una 
qualche sorgente di backup, il processo di aggiornamento sarà più complesso e dipenderà dal tipo di 
applicazione. A questo punto vogliamo già verificare che il DB venga efièttivamente creato la prima 
volta e quindi solamente aperto le volte successive. A tal proposito abbiamo, al momento, solo 
accennato alla classe DAOLocaiDataFragment, che descrive il fragment per la visualizzazione delle 
informazioni locali che prima avevamo solamente simulato. Per il momento quello che ci interessa è la 
modalità con cui il ciclo di vita dell'oggetto dao è stato vincolato a quello del fragment. Il codice di 
interesse è questo: 

private DAO mDao; 
@Override 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
mDao = DAO . get (getActivity ( ) ) ; 

} 

dOverride 

public void onStartO { 
super . onStart () ; 
mDao . open ( ) ; 
/ /setListAdapter (nuli) ; 

} 

SOverride 

public void onStopO { 
mDao . close ( ) ; 
super . onStop ( ) ; 

} 

All'interno del metodo onCreate o inizializziamo il dao passando il riferimento al particolare 
Context, che qui è l'activity che contiene il fragment. All'interno del metodo onstart ( ) provvediamo 
all'invocazione del metodo open o e quindi nel metodo onstop o invochiamo il metodo dose o 
mantenendo la simmetria delle chiamate rispetto all'invocazione dei metodi di callback attraverso il 
riferimento super. Sostituendo questo fragment al precedente all'interno della classe 
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LocaiDataActivity possiamo verificare cosa succede aiutandoci con il tool adb e AFile Manager 
che abbiamo già imparato a usare. Nella Figura 8.15 è riportata la struttura delle directory relativa alla 
nostra applicazione, la quale dimostra come in efiètti sia stato creato un database all'interno della 
cartella /databases associata all'applicazione. 
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Figura 8.15 Struttura a directory a seguito della creazione del database. 



Notiamo come il nome del file sia efièttivamente quello indicato e come sia presente anche un file 
che si chiama journal. È un file che SQLite crea e utilizza per una gestione affidabile delle transazioni, 
qualcosa che può essere disabilitato alfine di un'ottimizzazione dal punto divista delle prestazioni; noi 
decidiamo di mantenere la configurazione di default. 

Ma cosa c'è dentro il database appena creato? Per verificarlo accediamo al nostro emulatore (o 
dispositivo con i permessi di root) in modalità shell attraverso il comando 

db shell 

e quindi arriviamo alla cartella associata al DB della nostra applicazione attraverso le seguenti 
istruzioni: 

ed data/data 

ed uk . co .massimocarli . android . ugho 
ed databases 

che potevano essere eseguite come una sola. A questo punto utilizziamo un tool di nome sqiite3 
attraverso l'istruzione 

sqlite3 UghoDB 

ottenendo la visualizzazione delprompt dei comandi della console del DB come segue: 

SQLite version 3.7.11 2012-03-20 11:35:50 

Enter ".help" for instructions 

Enter SQL statements terminated with a ";" 

sqlite> 

Per verificare la presenza della tabella definita nel nostro file di configurazione è sufficiente eseguire 
il comando (attenzione al punto iniziale) 

. schema 

il cui risultato nel nostro caso è il seguente: 

CREATE TABLE HORO_VOTE ( 

_id integer PRIMARY KEY AUTO INCREMENT UNIQUE, 

entry_date date NOT NULL UNIQUE, 

love_vote integer NOT NULL, 

health_vote integer NOT NULL, 

work_vote integer NOT NULL, 

luck_vote integer NOT NULL, 

horo_sign text NOT NULL) ; 
CREATE TABLE andrò id_met adata (locale TEXT) ; 

CREATE INDEX UNIQUE_ENTRY_DATE ON HORO_VOTE (_id, entry_date) ; 
sqlite> 

a conferma della corretta esecuzione. Oltre a quanto da noi definito, notiamo anche la presenza di 
una tabella di nome android_metadata che il sistema gestisce in modo automatico e che quindi 
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trascuriamo. 

Abbiamo così creato una nostra classe dao che al momento ci permette di creare il DB e di legare 
il ciclo di vita dell'oggetto sQLiteDatabase a quello del componente che lo contiene. Un DB serve 
però per la memorizzazione e, soprattutto, l'estrazione di informazioni, come vedremo nel prossimo 
paragrafo. 

Esecuzione di comandi SQL 

Una volta creato il DB ci servono gli strumenti per poterci eseguire dei comandi SQL. Per fare 
questo si utilizzano alcuni metodi della classe SQLiteDatabase che possiamo classificare in: 

• execSQL 

• delete 

• insert 

• update 

• replace 

• query 

In precedenza abbiamo accennato alla possibilità di creare lo schema del DB attraverso opportuni 
metodi della classe SQLiteDatabase. Stavamo facendo infatti riferimento ai seguenti metodi con i quali 
si possono eseguire comandi SQL non di query (non select per intenderci): 

public void execSQL (String sql, Object[] bindArgs) 
public void execSQL (String sql) 

Vediamo che il primo overload dispone di un secondo parametro di nome bindArgs. È il caso in 
cui la query viene descritta con un meccanismo parametrizzato simile a quello di definizione delle 
preparedstatement conJDBC. Per intenderci, l'istruzione 

db. execSQL ("INSERT INTO HORO_VOTE (horo_sign, entry_date) VALUES (?,?)", new Object[] 
{ "Lion", now} ) ; 

permette la definizione di una query parametrizzata attraverso il primo parametro a cui vengono 
assegnati dei valori contenuti nel secondo parametro come array. Esaminando nel dettaglio le API del 
package androìd. database, il lettore potrà notare come si tratti di un'operazione che avviene in più 
passi, che possiamo riassumere nelle seguenti istruzioni: 

SQLiteStatement st = db . compileStatement (" INSERT INTO TEAM 

(horo_sign, entry_date) VALUES (?,?)"); 

st . bindString ( 1 , "Lion" ) ; 
st .bindString (2, now) ; 
st . execute ( ) ; 

Inizialmente il comando SQL viene compilato consentendone esecuzioni ripetute in modo 
ottimizzato. Il DB non dovrà infatti più compilare lo script ma semplicemente sostituire i valori 
corrispondenti ai placeholder (?) ed eseguire la query. 

ATTENZIONE 

L'indice del primo placeholder è 1 e non 0. 

Nella nostra implementazione di DAO non utilizzeremo questo metodo ma ci appoggeremo ad altri 
più specifici come quello che consente la cancellazione di un record. È possibile infatti eseguire 
l'equivalente di un delete SQL attraverso questa operazione: 

public int delete (String table, String whereClause, String [] whereArgs) 

dove i parametri ci permettono di specificare, rispettivamente, il nome della tabella e l'eventuale 
clausola where con i valori corrispondenti. Come esempio abbiamo implementato nel DAO la 
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seguente operazione: 

public int deleteByld ( final long id) { 
int deleteResult = -1; 
if (mDb. isOpen () ) { 

final String where = UghoDB.HoroVote._ID + " = ?"; 

final String [] whereArgs = new String []{ String . valueOf (id) } ; 

deleteResult = mDb . delete (UghoDB . HoroVote . TABLE_NAME , where, whereArgs); 

} 

return deleteResult; 

} 

Notiamo come sia stato utile creare anche ima classe di metadati, di nome ughoDB, contenente il 
nome del DB, delle diverse tabelle e relative colonne. Sarà ima classe che ci sarà utile anche 
successivamente quando tratteremo il content provider. Il metodo delete prevede il nome della 
tabella e due parametri che permettono di gestire la clausola where. Il primo è ima String che 
contiene la condizione con gli eventuali placeholder (?), mentre il secondo è un array di String che 
contiene gli eventuali valori nello stesso ordine. Nel nostro caso abbiamo creato il metodo che 
consente di cancellare un record dato il valore del campo _id associato alla costante corrispondente. 

NOTA 

Vedremo meglio in seguito, ma la costante _id non è stata da noi definita bensì ereditata 
dall'interfaccia androìd. provider. Basecoiumns a prova del fatto che si tratta di un nome di colonna 
caratteristico della piattaforma. 

Il valore di ritomo del metodo descrive il numero di elementi che sono stati influenzati 
dall'operazione, che nel caso di delete potranno essere 0, 1 oppure -1 nel caso in cui tentassimo di 
cancellare un elemento senza aver aperto il DB. 

NOTA 

Vediamo come non sia stata generata un'eccezione di tipo megaistateException come avremmo 
invece potuto fare per sottolineare il fatto che il DB non era stato aperto prima dell'esecuzione della 
query. 

Nel nostro esempio abbiamo già impostato i valori dei parametri where e whereArgs adattandoli 
all'operazione di cancellazione. Un valore nuli per il parametro where non causa alcun errore ma 
indica semplicemente l'assenza di qualunque filtro. 

Nel caso in cui si volesse eseguire un'operazione di insert, gli strumenti forniti dalla classe 

SQLiteDatabase SOnO questi: 

public long insert (String table, String nullColumnHack, Content Values values) 
public long insertOrThrow (String table, String nullColumnHack, ContentValues values) 

i quali introducono un nuovo tipo descritto dalla classe ContentValues del package 
androìd . content. E una sorta di Map in cui si può inserire una serie di valori assegnandoli a una 
particolare chiave di tipo string, che in questo caso è il nome di una colonna. Si tratta di una classe, 
che incontreremo anche nella gestione dei content provider, che ci offre una serie di metodi 
getAsxxx ( ) che semplificano l'utilizzo delle informazioni inserite nella gestione con i DB. Altro 
concetto importante è quello di null column hack, che rappresenta il nome di una colonna che può 
assumere null come possibile valore ma che merita un piccolo approfondimento. Supponiamo infatti 
di aver bisogno di inserire un record i cui valori di tutte le colonne sono null o corrispondenti ai 
relativi valori di default. In quel caso la nostra SQL sarebbe del tipo: 

INSERT INTO HORO_VOTE 

che in SQLIte non è un'istruzione valida in quanto è necessario specificare il valore di almeno una 
colonna. Attraverso la colonna denominata Null Column Hack la query precedente potrebbe 
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diventare del tipo: 

INSERT INTO HORO_VOTE (horo_sign) VALUES (NULL) 

che è compatibile con FSQL di SQLite. Si deve trattare di una colonna che può assumere il valore 
null, cosa che nel nostro caso non vera. A questo punto abbiamo due alternative: o permettiamo il 
valore null alla nostra colonna horo_sign oppure ne introduciamo un'altra da utilizzare in questi casi. 
Qui decidiamo di aggiungere la colonna location di tipo testo e di utilizzare questa come Null 
Column Hack. La modifica del DB comporta però delle difficoltà in quanto il DB che ora vogliamo 
considerare è diverso da quello già creato. Si ha quindi un problema di versioni che ci consente di 
dare un'implemetazione a quello che avevamo lasciato indefinito. Decidiamo allora la soluzione più 
semplice, che consiste nel drop del DB precedente e nella creazione della nuova tabella nel caso in cui 
la nuova versione sua successiva a quella esistente. Creiamo quindi il file drop_schema . sqi contenente 
la sola istruzione 

DROP TABLE HORO_VOTE; 

e modifichiamo il metodo open ( ) nel seguente modo: 

private static final int DB_VERSION = 1; 

public void open ( ) { 

ìf (mDb == null || !mDb. isOpen () ) { 

final File dbFile = mContext . getDatabasePath (UghoDB . DB_NAME) ; 
final boolean wasExisting = dbFile . exists () ; 
if (! wasExisting) { 

final String createDbStatement; 
try { 

createDbStatement = ResourceUtils 
. getRawAs String (mContext , R.raw. create_schema) ; 
DatabaseUtils . createDbFromSqlStatements (mContext , 
UghoDB .DB_NAME, DB_VERSION, createDbStatement); 
} catch (IOException e) { 
e . prìntStackTrace () ; 
return; 

} 

} 

mDb = mContext . openOrCreateDatabase (UghoDB. DB_NAME, Context . MODE_PRIVATE, null); 
int oldVersion = mDb . getVersion () ; 
if (oldVersion != DB_VERSION) { 
try { 

final String dropSchemaSql = ResourceUtils 
. getRawAsString (mContext , R . raw . drop_schema) ; 
mDb . execSQL (dropSchemaSql) ; 

final String createDbStatement = ResourceUtils 
. getRawAsString (mContext, R. raw. create_schema) ; 
mDb. execSQL (createDbStatement) ; 
} catch (IOException e) { 
e . prìntStackTrace ( ) ; 

} 

} 

} 

} 

Notiamo come la versione del DB della nostra applicazione sia stato ora incrementato e aggiunto al 
codice per la gestione dell' upgrade. Nel nostro caso abbiamo semplicemente utilizzato il metodo 
execSQL ( ) per eseguire lo script di eliminazione dello schema per poi ricreare il DB, che ora risulterà 
aggiornato. 

Nel caso in cui volessimo aggiungere le informazioni relative auniocaDataModei dovremo creare 
un contentvaiues e riempirlo con i valori delle diverse proprietà nel seguente modo: 

public long insert (final LocalDataModel data) { 
long newld = -1; 
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if (mDb. isOpen () ) { 

final ContentValues values = new ContentValues () ; 
values .put (UghoDB . HoroVote . ENTRY_DATE, data . entryDate) ; 
values. put (UghoDB . HoroVote . LOVE_VOTE, data . loveVote) ; 
values. put (UghoDB . HoroVote . HEALTH_VOTE, data . healthVote) ; 
values. put (UghoDB . HoroVote . WORK_VOTE, data . workVote) ; 
values. put (UghoDB . HoroVote . LUCK_VOTE, data . luckVote) ; 
// Inseriamo ì valori nel DB 

newld = mDb. insert (UghoDB. HoroVote. TABLE_NAME, UghoDB . HoroVote . LOCATION, 

values) ; 
} 

return newld; 

} 

In questo caso il valore di ritorno, in caso di successo, è l'id del nuovo elemento insertilo. La 
differenza tra i due metodi descritti sta nella possibilità di lanciare o meno un'eccezione di tipo 
SQLException in caso di errore. Nella precedente implementazione abbiamo inserito anche la 
creazione dell'oggetto di tipo ContentValues, che è spesso buona norma incapsulare all'interno 
dell'entità stessa in modo da poterla riutilizzare in più punti Per questo motivo abbiamo aggiunto alla 
classe LocaiDataModei questo metodo: 

public ContentValues asValuesO { 

final ContentValues values = new ContentValues () ; 
values. put (UghoDB. HoroVote. ENTRY_DATE, entryDate) ; 
values. put (UghoDB . HoroVote . LOVE_VOTE, loveVote) ; 
values. put (UghoDB . HoroVote . HEALTH_VOTE, healthVote) ; 
values. put (UghoDB . HoroVote . WORK_VOTE, workVote) ; 
values. put (UghoDB . HoroVote . LUCK_VOTE, luckVote) ; 
return values; 

} 

il quale ci permette di modificare la classe dao semplificando il metodo insert o che diventa ora: 

public long insert (final LocalDataModel data) { 
long newld = -1; 
ìf (mDb. isOpen () ) { 

final ContentValues values = data . asValues ( ) ; 

newld = mDb. insert (UghoDB. HoroVote. TABLE_NAME, UghoDB . HoroVote . LOCATION, 

values) ; 
} 

return newld; 

} 

Il successivo metodo che esaminiamo è quello che ci consente di eseguire un update, ovvero: 

public int update (String table, ContentValues values, String whereClause, String[] 
whereArgs) 

e prevede, oltre al nome della tabella, un oggetto di tipo ContentValues con i nuovi valori da 
aggiornare e quindi le eventuali informazioni relative alla clausola where da gestire come nel caso 
precedente. In base a quanto detto, aggiungiamo il seguente metodo al nostro DAO: 

public int update (final LocalDataModel data) { 
int updated = -1; 
ìf (mDb. isOpen () ) { 

final ContentValues values = data . asValues () ; 

final String where = UghoDB . HoroVote ._ID + " = ?" ; 

final String[] whereArgs = new String []{ String . valueOf (data . id) } ; 

updated = mDb. update (UghoDB. HoroVote. TABLE_NAME, values, where, whereArgs); 

} 

return updated; 

} 

Il metodo di update precedente necessita di una precisazione legata al fatto che esso eseguirà 
l'aggiornamento delle sole proprietà contenute in ContentValues e nell'oggetto LocalDataModel 
passato (l'id dovrà comunque essere presente) lasciando inalterate le altre. Nel caso in cui volessimo 
sostituire tutte le colonne con i valori contenuti nell'oggetto passato, potremo utilizzare uno di questi 
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metodi; 

public long replace (String table, String nullColumnHack, ContentValues initialValues ) 
public long replaceOrThrow (String table, String nullColumnHack, ContentValues 
initialValues ) 

La firma è la stessa del metodo insert ( ) ed è un modo veloce per rimpiazzare i valori di un 
particolare record attraverso una singola istruzione. 

Estrazione dei dati e Cursor 

Nel paragrafo precedente abbiamo visto come eseguire degli script SQL per l'esecuzione di query 
dette di update, ovvero che producono delle variazioni nei dati del DB. In questo paragrafo ci 
occuperemo invece delle API per l'estrazione delle informazioni A tale proposito prendiamo come 
riferimento la versione più complessa dei metodi della classe sQLiteDatabase, ovvero il seguente: 

public Cursor query (boolean distinct, String table, Stringi] columns, 

String selection, String [] selectionArgs, String groupBy, 
String having, String orderBy, String limit) 

Attraverso il parametro distinct non facciamo altro che specificare se la query da eseguire dovrà 
essere del tipo select distinct oppure semplicemente select. Attraverso table specifichiamo il 
nome della tabella da leggere, mentre il parametro coiums è un array dei nomi delle colonne che 
intendiamo estrarre. I parametri selection e selectionArgs permettono di impostare le informazioni 
relative alla clausola where secondo le stesse modalità già viste. I parametri successivi sono 
abbastanza ovvi: consentono di specificare se inserire all'interno della query dei comandi di group by, 
having e order by rispettivamente, specificando i nomi delle colonne corrispondenti Come ultimo 
parametro è possibile specificare il valore di limit, ovvero delle informazioni spesso utili al fine della 
paginazione dei risultati Osservando le API nella documentazione ufficiale, possiamo notare come vi 
siano diverse versioni di questo metodo tutte caratterizzate da un valore di ritomo di tipo cursor. 
Come accennato, cursor è un'interfaccia del package android . database, che permette di astrarre il 
concetto di cursore per l'accesso ai risultati di una query. Possiamo pensare a un cursore come a un 
puntatore verso uno dei dati risultato di una query. È importante notare come la posizione iniziale sia 
precedente al primo (eventuale) elemento, come vedremo meglio successivamente. 

Per ritornare ai nostri famosi design pattern possiamo pensare a cursor come all'implementazione 
del pattern GoF Iterator, che consente di scorrere un insieme di informazione in modo indipendente 
da come sono memorizzate. Per capirne l'utilità prendiamo per esempio a una List che è 
caratterizzata dall'avere gli elementi imo di seguito all'altro ammettendo delle ripetizioni Se volessimo 
scorrere tutti i suoi elementi una soluzione potrebbe essere quella di utilizzare un indice con valori 
compresi tra 0 e la lunghezza - 1 . Se invece di una List avessimo un set per il quale non esiste il 
concetto di ordine è evidente che non potremmo utilizzare lo stesso meccanismo e quindi saremmo 
costretti a modificare il nostro codice. Iterator ci permette di ovviare a questo problema facendoci 
scorrere gli elementi delle due strutture allo stesso modo, che si può riassumere in due domande: 

• Ci sono ancora elementi? 

• Se sì, dammi l'elemento corrente e vai al prossimo. 

Nel caso del nostro cursor il pattern Iterator viene implementato attraverso una serie di 
operazioni che si possono classificare in operazioni di 

• movimento; 

• controllo; 
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• accesso ai dati 



Al primo gruppo appartengono le operazioni che consentono di modificare la posizione del 
cursore, tra cui possiamo elencare le seguenti: 

public abstract int getPosition ( ) 
public abstract boolean move (int offset) 
public abstract boolean moveToFirst ( ) 
public abstract boolean moveToLast ( ) 
public abstract boolean moveToNextO 

public abstract boolean moveToPosition ( int position) 

public abstract boolean moveToPrevious ( ) 

public abstract boolean isAf terLast ( ) 

public abstract boolean isBef oreFirst ( ) 

public abstract boolean isFìrstO 

public abstract boolean isLastO 

Si tratta di operazioni che, tranne la prima, ritornano un valore di tipo boolean che indica la 
disponibilità o meno di altre informazioni. Per esempio, un valore di ritomo pari a true del metodo 
moveToNext ( ) indica che si è arrivati all'ultimo elemento disponibile. 

Di solito si eseguono delle query di cui si conosce già la struttura dei risultati. Esistono comunque 
alcuni metodi che ci possono venire in aiuto nel caso in cui questo non fosse vero e in particolare: 

public abstract boolean isClosedO 

public abstract boolean isNull(int columnlndex) 

public abstract int getColumnCount ( ) 

public abstract Stringi] getColumnNames ( ) 

public abstract int getCountt) 

il cui significato è piuttosto chiaro. L'oggetto cursor è comunque fondamentale in quanto ci dà la 
possMtà di accedere di dati risultato di una query. Per fare questo esistono una serie di metodi 
getxxx ( ) per ciascuno dei tipi supportati Tra i più importanti abbiamo: 

public abstract byte[] getBlob(int columnlndex) 
public abstract doublé getDouble (int columnlndex) 
public abstract int getlnt (int columnlndex) 
public abstract String getString (int columnlndex) 

Come avviene per le diverse implementazioni di Iterator, la modalità discorrimento delle 
informazioni segue un procedimento che può essere descritto brevemente attraverso queste righe di 
codice: 

int sìgnlndex = cursor . getColumnlndex (UghoDB . HoroVote . HORO_SIGN) ; 
int datelndex = cursor . getColumnlndex (UghoDB . HoroVote . ENTRY_DATE) ; 
int lovelndex = cursor . getColumnlndex (UghoDB . HoroVote . LOVE_VOTE) ; 
while (cursor .moveToNext ( ) ) { 

String signName = cursor . getString ( signlndex) ; 

long dateEntry = cursor . getLong (datelndex) ; 

int loveVote = cursor . getlnt (lovelndex) ; 

// Utilizziamo l'informazione 

} 

cursor . close ( ) ; 

Vediamo come l'accesso al valore di un campo avvenga attraverso il relativo metodo getxxx ( ) , 
che accetta come parametro la posizione della colonna corrispondente. Si tratta comunque di 
un'informazione disponibile attraverso il metodo getColumnlndex ( ) , il quale ci fornisce l'indice di una 
colonna dato il relativo nome. L'esempio precedente ha estratto le informazioni accessibili dal cursore 
per poi elaborarle in qualche modo. Infine, l'invocazione del metodo moveToNext ( ) è stata utilizzata 
all'interno del ciclo while. Ciascuno dei metodi di movimento ritorna infatti un valore booleano che 
indica se il cursore è arrivato al termine dei dati disponibili oppure no .Un valore di ritorno pari a 
false indica che non sono più disponibili dati e il ciclo può tenninare. È un meccanismo molto simile a 
quello utilizzato in JDBC con Resuitset. Da non dimenticare la liberazione delle risorse associate al 
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cursore attraverso l'invocazione del suo metodo dose o . 

Per quello che riguarda il metodo di query nel nostro DAO abbiamo diverse opzioni. La peggiore, 
per diversi motivi, è sicuramente la seguente: 

public LocalDataModel [ ] worseQuery (String where, Stringi] whereArgs) { 
LocalDataModel [ ] result = nuli; 
if (mDb. isOpen () ) { 

final Cur sor cur sor = mDb . query (UghoDB . HoroVote . TABLE_NAME , 

nuli, where, whereArgs, nuli, nuli, nuli) ; 
result = new LocalDataModel [cursor . getCount ()] ; 
int index = 0; 

while (cursor . moveToNext () ) { 

long ìd = cursor . getLong (cursor . getColumnlndex (UghoDB . HoroVote ._ID) ) ; 
long entryDate = cursor . getLong (cursor . getColumnlndex ( 

UghoDB. HoroVote. ENTRY_DATE) ) ; 
int loveVote = cursor . getlnt (cursor . getColumnlndex ( 

UghoDB. HoroVote. LOVE_VOTE) ) ; 
int healthVote = cursor . getlnt (cursor . getColumnlndex ( 

UghoDB . HoroVote . HEALTH_VOTE ) ) ; 
int workVote = cursor . getlnt (cursor . getColumnlndex ( 

UghoDB. HoroVote. WORK_VOTE) ) ; 
int luckVote = cursor . getlnt (cursor . getColumnlndex ( 

UghoDB. HoroVote. LUCK_V0TE) ) ; 
LocalDataModel item = LocalDataModel . create (id, entryDate, loveVote, 

healthVote, workVote, luckVote) ; 

result [index++] = item; 

} 

cursor . close ( ) ; 

} 

return result; 

} 

Il problema principale è che i dati vengono estratti tutti dal cursore e quindi ritornati all'interno di un 
array. Cosa succederebbe infatti nel caso di un numero elevatissimo di dati? Ci sarebbe buona 
probabilità di avere un outofMemoryError, nemico numero uno per chi sviluppa im ambito mobile. Un 
altro problema è poi a livello di stile: il mapping tra il LocalDataModel e le colonne estratte dal DB non 
è incapsulato a dovere, e per risolvere la situazione abbiamo diverse soluzioni. La prima consiste nel 
creare, all'interno della classe LocalDataModel un metodo statico di Factory che crea l'istanza a 
partire da un oggetto cursor (posizionato correttamente) come segue: 

public static LocalDataModel fromCur sor ( final Cursor cursor) { 

long ìd = cursor . getLong (cursor . getColumnlndex (UghoDB . HoroVote ._ID) ) ; 
long entryDate = cursor . getLong (cursor . getColumnlndex (UghoDB . HoroVote . ENTRY_DATE) ) ; 
int loveVote = cursor . getlnt (cursor . getColumnlndex (UghoDB . HoroVote . LOVE_VOTE) ) ; 
int healthVote = cursor . getlnt (cursor . getColumnlndex (UghoDB . HoroVote . HEALTH_VOTE) ) ; 
int workVote = cursor . getlnt (cursor . getColumnlndex (UghoDB . HoroVote .WORK_VOTE) ) ; 
int luckVote = cursor . getlnt (cursor . getColumnlndex (UghoDB . HoroVote . LUCK_VOTE) ) ; 
LocalDataModel item = LocalDataModel . create ( id, entryDate, loveVote, 

healthVote, workVote, luckVote) ; 

return item; 

} 

Per ovviare al problema di memoria possiamo poi restituire direttamente il cursor, la cui gestione 
dovrà essere dell'oggetto chiamante. Per il nostro DAO decidiamo di implementare come prima cosa 
uno speciale iteratore in grado di ritornare istanze di LocalDataModel a partire dal cursor. Abbiamo 
quindi implementato questo metodo: 

public Iterator<LocalDataModel> querylterator (String where, String [] whereArgs) { 
Iterator<LocalDataModel> resultlterator = nuli; 
/ / We execute the query 
ìf (mDb. isOpen () ) { 

final Cursor cursor = mDb . query (UghoDB . HoroVote . TABLE_NAME, 

nuli, where, whereArgs, nuli, nuli, nuli) ; 
resultlterator = new Iterator<LocalDataModel> ( ) { 
SOverride 
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public boolean hasNextt) { 

boolean moreData = cursor . moveToNext () ; 
if ( ImoreData) { 

// Chiudiamo il cursore se non ci sono dati 

cursor . close ( ) ; 

} 

return moreData; 

} 

@Override 

public LocalDataModel next() { 

return LocalDataModel . fromCursor (cursor) ; 

} 

SOverride 

public void remove ( ) { 
} 

}; 

} else { 

// Creiamo un'implementazione vuota 
resultlterator = new Iterator<LocalDataModel> ( ) { 
SOverride 

public boolean hasNextO { 
return false; 

} 

SOverride 

public LocalDataModel next() { 
return nuli; 

} 

@Override 

public void remove ( ) { 
} 

}; 

} 

// Ritorniamo l'Iterator 
return resultlterator; 

} 

Vediamo come il metodo ritorni un' implementazione dell' interfaccia iterator<LocaiDataModei> e 
come il cursore associato venga chiuso quando avremo percorso tutti i valori in esso contenuti Nel 
caso in cui non vi fossero risultati ritorniamo un'implementazione vuota, ovvero il cui metodo next ( ) 
ritorna sempre false. Osservando meglio questa soluzione possiamo comprendere come essa 
permetta di iterare i diversi risultati in modo efficiente, anche se non è comunque il massimo dal punto 
divista dell'integrazione con la piattaforma Andro id. Per questo motivo aggiungiamo la seguente 
implementazione: 

public Cursor sìmpleQuery ( final String where, final Stringi] whereArgs) { 
Cursor cursor = nuli; 
ìf (mDb. isOpen () ) { 

cursor = mDb . query (UghoDB . HoroVote . TABLE_NAME, nuli, where, 
whereArgs, nuli, nuli, nuli) ; 

} 

return cursor; 

} 

che notiamo ritorna direttamente il cursor, che dovrà essere gestito dall'oggetto che ha invocato il 
metodo. Potrà quindi utilizzare il metodo statico fromCursor o della classe LocalDataModel per 
estrarre le informazioni dal cursor e incapsularle in un' istanza della stessa classe. In questa fase ci può 
comunque venire in aiuto quanto visto in relazione all'interfaccia sQLiteDatabase.cursorFactory. 
Facciamo infatti in modo che l'implementazione di Cursor di ritorno non sia quella standard ma una 
nostra specializzazione alla quale abbiamo aggiunto dei metodi che permettono di estrarre le 
informazioni che ci servono. Per questo motivo abbiamo realizzato la seguente implementazione 
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dell'interfaccia di Factory la quale ritorna un'istanza della classe 

LocaiDataCursorFactory . LocaiDataCursor con alcuni metodi specifici del nostro scenario: 

SSuppressWarnìngs ( "deprecation" ) 

public class LocalDataCursorFactory implements SQLiteDatabase . CursorFactory { 

public static class LocalDataCursor extends SQLiteCursor { 

public LocalDataCursor (SQLiteDatabase sqLiteDatabase, 

SQLiteCursorDriver sqLiteCur sor Driver, 
String editTable, SQLiteQuery sqLiteQuery) { 
super (sqLiteDatabase, sqLiteCursorDriver , editTable, sqLiteQuery); 

} 

public long getld() { 

return getLong (getColumnlndex (UghoDB . HoroVote ._ID) ) ; 

} 

public long getEntryDate ( ) { 

return getLong (getColumnlndex (UghoDB . HoroVote . ENTRY_DATE) ) ; 

} 

public int getLoveVote ( ) { 

return getlnt (getColumnlndex (UghoDB . HoroVote . LOVE_VOTE) ) ; 

} 

public int getHealthVote ( ) { 

return getlnt (getColumnlndex (UghoDB . HoroVote . HEALTH_VOTE) ) ; 

} 

public int getWorkVote ( ) { 

return getlnt (getColumnlndex (UghoDB . HoroVote . WORK_VOTE) ) ; 

} 

public int getLuckVote ( ) { 

return getlnt (getColumnlndex (UghoDB . HoroVote . LUCK_VOTE) ) ; 

} 

public LocalDataModel asLocalDataModel ( ) { 

return LocalDataModel . create (getld ( ) , getEntryDate ( ) , 
getLoveVote ( ) , getHealthVote ( ) , getWorkVote ( ) , getLuckVote ( ) ) ; 

} 

} 

gOverride 

public Cursor newCur sor (SQLiteDatabase sqLiteDatabase, 

SQLiteCursorDriver sqLiteCursorDriver, 
String editTable, SQLiteQuery sqLiteQuery) { 
return new LocalDataCursor (sqLiteDatabase, sqLiteCursorDriver, 

UghoDB . HoroVote . TABLE_NAME , sqLiteQuery) ; 

} 

} 

La nostra implementazione di cursor aggiunge alcuni metodi che ci consentono di accedere 
direttamente ad alcune informazioni della tabella oppure all'intera riga incapsulando le informazioni 
all'interno del solito oggetto di tipo LocalDataModel. Per poter utilizzare questa nostra 
implementazione dovremo dichiararla in fase di apertura del DB che, nella classe dao, da 

mDb = mContext . openOrCreateDatabase (UghoDB. DB_NAME, Context .MODE_PRIVATE, nuli) ; 

diventa 

final SQLiteDatabase . CursorFactory CursorFactory = new LocalDataCursorFactory ( ) ; 

mDb = mContext. openOrCreateDatabase (UghoDB. DB_NAME, Context . MODE_PRIVATE, 
CursorFactory) ; 

e quindi andare a modificare il tipo del cursore di ritorno dal metodo simpleQuery definendo il 



metodo customQuery nel seguente modo: 

public LocalDataCursorFactory . LocalDataCursor customQuery ( 
final String where, final String[] whereArgs) { 
LocalDataCursorFactory . LocalDataCursor cursor = nuli; 
if (mDb. isOpen () ) { 

cursor = (LocalDataCursorFactory . LocalDataCursor) 

mDb . query (UghoDB . HoroVote . TABLE_NAME , nuli , 
where, whereArgs, nuli, nuli, nuli) ; 

} 

return cursor; 

} 

Sicuri del tàttO Che LocalDataCursorFactory. LocalDataCursor Sarà proprio il tipo del Cursor di 

ritorno dall'esecuzione del metodo query. Un'ultima considerazione riguarda la necessità di utilizzare 
delle annotazioni del tipo SSuppressWarnings ( "deprecation " ) dovute alla presenza di metodi 
deprecati Vedremo successivamente come eliminare anche questi problemi attraverso l'utilizzo di API 
più idonee e integrate con la piattaforma. 

Adapter per l'accesso al DB 

Nei paragrafi precedenti abbiamo visto come creare una implementazione diDAO (Data Access 
Object) che ci consentisse di accedere al nostro DB. Sebbene questa non rappresenti, come 
vedremo successivamente, la soluzione migliore, può comunque essere utilizzata per descrivere alcune 
implementazioni di Adapter per l'accesso al DB. A tale proposito abbiamo modificato la classe 
DAOLocaiDataFragment in modo che la stessa vada a prendere le informazioni proprio dal nostro DB 
utilizzando ilDAO. Prima di descrivere questa classe dobbiamo però verificare come i dati vengono 
inseriti al fine di non avere sempre la lista vuota. Abbiamo quindi modificato la classe 

NewDataFragment. 
NOTA 

La semplificazione fatta per la classe NewDataFragment per l'inserimento delle informazioni rende 
superfluo il lavoro fatto per la gestione sui tablet. Lasciamo al lettore come esercizio la 
personalizzazione di questa schermata, che al momento contiene dei componenti di tipo Ratinar. 

Anche questa classe utilizza il nostro DAO per l'inserimento delle informazioni raccolte e, 
soprattutto, si integra con esso in relazione al proprio ciclo di vita. Per quello che riguarda la 
valorizzazione e la gestione delle RatìngBar non vi è nulla di nuovo (se non gli stessi componenti 
RatingBar). Vediamo invece solamente le parti che implicano un'interazione con il DB e i seguenti 
metodi; 

dOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setHasOptionsMenu (true) ; 
mDao = DAO . get (getActivity ( ) ) ; 

} 

@Override 

public void onStartf) { 
super . onStart ( ) ; 
mDao . open ( ) ; 

final String where = UghoDB . HoroVote . ENTRY_DATE + " = ?" ; 
final String [ ] whereArgs = new String [ ] 

{String. valueOf (mCurrentDate . getTimelnMillis () ) } ; 
LocalDataCursorFactory . LocalDataCursor localDataCursor = 

mDao . customQuery (where , whereArgs ) ; 
mDataExisting = localDataCursor . moveToNext () ; 
ìf (mDataExisting) { 

final LocalDataModel currentModel = localDataCursor . asLocalDataModel () ; 
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// The data is already present so we disable the RatingBar after the value 
in jection 

mLoveRatingBar . setRating (currentModel . loveVote) ; 
mLoveRatingBar . setEnabled (false) ; 

mHealthRatingBar . setRating (currentModel . healthVote) ; 
mHealthRatingBar . setEnabled (false) ; 
mWorkRatingBar . setRating (currentModel . workVote) ; 
mWorkRatingBar . setEnabled ( false) ; 
mLuckRatingBar . setRating (currentModel . luckVote) ; 
mLuckRatingBar . setEnabled (false) ; 
} else { 

// Non sono presenti dati 

} 

} 

private void additemi) { 

LocalDataModel newData = LocalDataModel . create (0 , 

mCurrentDate . getTimelnMillis ( ) , (int) mLoveRatingBar . getRating () , 
(int) mHealthRatingBar . getRating () , (int) 

mWorkRatingBar . getRating ( ) , ( int ) mLuckRatingBar . getRating ( ) ) ; 
mDao . insertWithSign (newData, mUserZodiac . name ( ) ) ; 

getActivìty ( ) . finish ( ) ; 

} 

@0verride 

public void onStopO { 
mDao.closeO ; 

super . onStop ( ) ; 

} 

Nel metodo oncreateo abbiamo ottenuto il riferimento all'oggetto DAO, che nel metodo 
onstart ( ) abbiamo aperto per poi richiuderlo nel metodo onstop ( ) . Nel metodo onstart ( ) abbiamo 
poi verificato se esiste già un'entry per la data corrente. In caso positivo non permetteremo l'editing e 
rinserimento del dato. In caso contrario abilitiamo il pulsante di inserimento, che non fa altro che 
raccogliere le informazioni per inserirle attraverso il metodo i nsertWithSign ( ) che abbiamo aggiunto 
al DAO perché il segno è comunque un'informazione obbligatoria. Il lettore potrà inserire il proprio 
giudizio relativamente ai quattro aspetto gestiti dall'applicazione e quindi ritornare alla visualizzazione 
dei dati nella lista. Ora i dati vengono estratti dal DB e non più da una struttura in memoria, per cui ciò 
che andremo a cambiare sarà l'implementazione di Adapter, che ora è del tipo sì mpleCur sor Adapter, 
come possiamo vedere nel seguente frammento di codice della classe DAOLocaiDataFragment: 

public void onStartO { 
super . onStart () ; 
mDao . open ( ) ; 

mAdapter = new SimpleCursorAdapter (getActivity () , 

R. layout . custom_list_item, mDao . customQuery (nuli , nuli), FROM, TO) ; 

mAdapter . setViewBinder (new SimpleCursorAdapter . ViewBinder ( ) { 

@0verride 

public boolean setViewValue (View view, Cursor cursor, int i) { 

final TextView outputTextView = (TextView) view; 
final LocalDataCursorFactory . LocalDataCursor ldCursor = 
(LocalDataCursorFactory . LocalDataCursor) cursor; 

// Dobbiamo rilevare l'elemento e mostrarlo 
switch ( view . get Id ( ) ) { 

case R . id . list_item_date : 

outputTextView. setText (DATE_FORMAT . format (ldCursor . getEntryDate ( ) ) ) ; 

break; 

case R. id. list_item_love_vote : 

outputTextView . setText (getResources ( ) 

. getString (R. string . love_value_pattern, 
ldCursor . getLoveVote 0 ) ) ; 

break; 

case R. id. list_item_health_vote : 

outputTextView . setText (getResources () 

. getString (R. string . health_value_pattern, 
ldCursor . getHealthVote () ) ) ; 
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break; 

case R . id . list_item_work_vote : 

outputTextView. setText (getResources () 

. getString (R . string . work_value_pattern, 
ldCursor . getWorkVote ( ) ) ) ; 

break; 

case R . id . list_item_luck_vote : 

outputTextView. setText (getResources () 

. getString (R. string . luck_value_pattern, 
ldCursor . getLuckVote 0 ) ) ; 

break; 

} 

return true; 

} 

}) ; 

setListAdapter (mAdapter) ; 

} 

Come possiamo notare l'astrazione introdotta attraverso il concetto di adapter non ci ha costretto 
a tante modifiche. Abbiamo semplicemente utilizzato un simpieCursorAdapter che, rispetto alla classe 
simpieAdapter vista in precedenza, legge le informazioni da un cursor che abbiamo passato 
attraverso l'istruzione: 

mDao . customQuery (nuli, nuli) 

non avendo messo infatti alcuna clausola where. Come nell'esempio in memoria, anche in questo 
caso abbiamo mappato i valori nel cursore con gli elementi della UI di riga attraverso un viewBinder, 
facendo attenzione che questa volta si tratta di un'interfaccia definita in simpieCursorAdapter e 
dispone di un'operazione leggermente diversa rispetto al cugino della classe simpieAdapter. 
L'operazione da implementare ora ha la firma 

public boolean setViewValue (View view, Cursor cursor, int i) 

e quindi contiene il riferimento alcursor, che nel nostro caso sappiamo essere un'implementazione 
della nostra classe LocaiDataCursorFactory .LocaiDataCursor di cui abbiamo utilizzato i metodi di 
utilità. 

Abbiamo visto come sia possibile gestire l'accesso a un DB di cui abbiamo creato lo schema e 
gestito le versioni. Fortunatamente, esistono anche dei metodi migliori e integrati con la piattaforma. 
Prima di questo vediamo però altri strumenti che possono aiutarci nell'esecuzione delle query e nella 
loro ottimizzazione. 

Esecuzione di query raw 

Nel caso in cui si intendesse eseguire direttamente una select, la classe SQLiteDatabase ci mette a 
disposizione le seguenti operazioni: 

public Cursor rawQuery (String sql, String [] selectionArgs ) 

public Cursor rawQueryWithFactory (SQLiteDatabase . CursorFactory cursorFactory, String 
sql, Stringi] selectionArgs, String editTable) 

dove esiste la possibilità di utilizzare dei placeholder ? all'interno della query assegnando poi a essi 
dei valori attraverso il parametro s electionArgs ottenendo in risposta sempre un riferimento a 
un'implementazione di cursor. Sono metodi molto utili nel caso in cui si abbia la necessità di eseguire 
query di struttura più complessa in modo da sfruttare al massimo le feature di SQLite. 

Gestione delle transazioni 

SQLite è un database molto compatto che però fornisce molti degli strumenti di un normale 
DBMS, primi fra tutti la gestione delle transazioni. A tale proposito notiamo, nella classe 
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SQLiteDatabase, la presenza dell'operazione 

public void beginTransaction ( ) 

che permette l'inizio di una transazione che si concluderà invece attraverso l'esecuzione di 

public void endTransaction ( ) 

È importante sottolineare come il successo o il fallimento di una transazione siano determinati dal 
metodo 

public void setTransactionSuccessf ul ( ) 

che consente di indicare come le operazioni nella transazione siano state eseguite, e da cui ci si 
attende un commit al termine della stessa. In caso contrario, al momento della sua conclusione, la 
transazione fallirà con conseguente rollback. È importante sottolineare come in Andro id sia possibile 
gestire delle transazioni innestate una nell'altra. Possiamo dire infatti che la transazione esterna fallirà 
se solo una delle transazioni contenute non verrà conclusa con successo, ovvero se per ciascuna di 
esse non è stato invocato il metodo s etTransactionSuccessf ul ( ) . Tipicamente il codice utilizzato è 
questo: 

//La transazione inizia 
db .beginTransaction () ; 
try { 

// Alcune query al DB e operazioni SQL 
// Se la transazione ha successo 
db . setTransactionSuccessful ( ) ; 
} finally { 

//La transazione è finita 
db . endTransaction ( ) ; 

} 

All'inizio si apre la transazione e successivamente si eseguono le relative operazioni all'interno di un 
blocco try/catch, dove l'ultima istruzione è quella che notifica il successo della transazione. Nel caso 
di eccezioni tale conferma non viene eseguita, per cui la conseguente terminazione della transazione 
porta al rollback della stessa. Nel caso tutto proceda correttamente, l'istruzione di transazione che 
ha avuto successo viene eseguita con conseguente commit. È importante notare come la transazione 
ha successo anche se tra l'esecuzione dei metodi setTransactionSuccessful o ed 
endTransaction ( ) vengono generati degli errori È quindi buona norma fare in modo che la seconda 
venga eseguita, in caso di successo, subito dopo la prima senza altre istruzioni intermedie. 

Il lettore potrà consultare le API della classe SQLiteDatabase per notare la presenza di alcuni 
metodi del tipo yieidi f contendedsaf eiy ( ) , i quali permettono di sospendere temporaneamente una 
transazione alfine dell'esecuzione di un particolare thread. Sempre in questo contesto possiamo 
notare la presenza del metodo : 

public void beginTransactionWithListener (SQLiteTransactionLìstener transactìonListener) 

il quale consente di iniziare la transazione specificando un'implementazione dell'interfaccia 
SQLiteTransactionLi stener, che permette la notifica degli eventi di inizio, commit e rollback 
all'eventuale listener. Per concludere notiamo la presenza dell'operazione 

public boolean inTransactìon () 

per la verifica dell'esistenza o meno di una transazione in atto. 

L'utilizzo delle transazioni nell'interazione con il DB è sempre auspicabile per garantire la 
consistenza delle informazioni ma soprattutto per ottenere un ragguardevole aumento delle 
performance. Specialmente nel caso di operazioni in batch (in numero considerevole), l'utilizzo delle 
transazioni porta a un sensibile miglioramento del tempo di esecuzione. 
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La classe SQLiteOpenHelper 

Se pensiamo a una classica applicazione che utilizza un proprio database privato per la gestione dei 
dati, è semplice comprendere come ci si possa trovare di fronte a problematiche abbastanza ricorrenti 
relative alla modalità di creazione e aggiornamento del database stesso. Come visto nella creazione 
del nostro DAO, la prima volta che l'utente esegue l'applicazione si ha la necessità di creare il 
database se non esiste, mentre nelle esecuzioni successive la necessità sarà quella di verificare la 
disponibilità di eventuali aggiornamenti e poi applicarli. A tale scopo Andro id mette a disposizione la 
classe SQLiteOpenHelper, la quale si occupa appunto di gestire le situazioni di creazione e 
aggiornamento di un database SQLite. Per comprenderne il funzionamento ne descriviamo 
velocemente il costruttore e le operazioni principali Per creare un oggetto di questo tipo è sufficiente 
utilizzare il costruttore 

public SQLiteOpenHelper (Context context, String name, 

SQLìteDatabase . CursorFactory factory, int versìon) 

il quale contiene, oltre agli ormai noti parametri, un identificatore di versione. È un valore intero che 
ci permetterà di capire se il database è da aggiornare oppure no. È bene sottolineare come l'utilizzo 
classico di un SQLiteOpenHelper consista nella creazione di una sua estensione, la quale esegue 
l'override di alcuni metodi di callback chiamati quando occorre creare o aggiornare il database. I 
controlli vengono fatti in corrispondenza dell'esecuzione di alcuni metodi che consentono di ottenere il 
riferimento al database. Il primo di questi è 

public synchronized SQLiteDatabase getWritableDatabase ( ) 

il quale permette di ottenere il riferimento all'oggetto di tipo SQLìteDatabase per l'accesso, sia in 
lettura sia in scrittura, al database corrispondente. Da notare come si tratti di un metodo 
synchronized per impedire problematiche relative alla creazione del DB da parte di più thread. Nel 
caso in cui si intendesse ottenere il riferimento al database solamente in lettura, il metodo da invocare 
sarà invece questo: 

public synchronized SQLiteDatabase getReadableDatabase ( ) 

L'aspetto interessante della classe SQLiteOpenHelper, che ne giustifica l'utilità, riguarda la 
possibilità di gestire la creazione e l'aggiornamento del database semplicemente facendo l'override di 
alcune operazioni Nel caso in cui il database non fosse presente, questa classe invocherà 
automaticamente il proprio metodo 

public abstract void onCreate (SQLiteDatabase db) 

mentre nel caso di esigenze di aggiornamento il metodo invocato sarà questo: 

public abstract void onUpgrade (SQLiteDatabase db, int oldVersion, int newVersion) 

È chiaro come la logica della creazione e dell'aggiornamento di un DB dovrà essere inserita 
all'interno degli override dei relativi metodi 

La classe SQLiteOpenHelper mette a disposizione anche un metodo di callback chiamato in 
corrispondenza dell'apertura del DB come punto di estensione per l'aggiunta di eventuali operazioni 
da eseguire in corrispondenza di quell'evento. 

È quindi di una classe che si utilizza molto spesso nella gestione dei database da parte di 
un'applicazione, come vedremo durante la creazione del nostro content provider. Lasciamo al lettore 
l'aggiornamento della classe DAO con l'aggiunta di questa utile classe. 

Content provider 

360 



Finora abbiamo visto diversi modi di gestire la persistenza dei dati, ricordando più volte di come si 
tratti di informazioni private di ogni applicazione. Esistono però determinati tipi di risorse che, per la 
natura stessa diAndroid, dovrebbero essere condivise, come per esempio l'insieme dei contatti, dei 
media o deibookmark. Proprio per questo motivo la piattaforma Andro id ha ideato dei componenti 
che si chiamano content provider, i quali permettono l'accesso a un particolare insieme di 
informazioni attraverso un'interfaccia standard che ricorda da vicino quelli che sono i servizi REST 
{REpresentational State Transfer). 

A ciascun content provider possono essere associati uno o più URI del tipo: 

content : / / <authority>/path 

Mentre la parte che abbiamo indicato come authority caratterizza in modo univoco il particolare 
content provider, la parte denominata path consente di specificare il tipo di risorsa in esso 
memorizzata. Nel nostro caso, per esempio, potremmo associare le risorse di tipo horo_vote a un 
URI del seguente tipo: 

content : //uk . co .massimocarli . android . ugho/horovote 

per l'elenco di tutte le entry oppure questo 

content : //uk . co . massimocarli . android . ugho/horovote/ <id> 

nel caso di una singola riga carattarizzata da un valore della chiave _id. Per esempio, FURI 
associato alla risorsa di identificatore 12 sarà il seguente: 

content : //uk . co .massimocarli . android . ugho/horovote/ 12 

NOTA 

Teoricamente l'authority può essere una qualunque stringa, ma è sempre bene legarla in qualche 
modo all'applicazione che definisce il content provider associato. 

I content provider sono di fondamentale importanza anche nel meccanismo di intent resolution, 
ovvero in quell'insieme di regole che permettono di individuare il particolare componente in grado di 
soddisfare un particolare intent. È infatti responsabilità del content provider indicare il particolare 
content type associato a un determinato URI. Nel Capitolo 3 abbiamo solo accennato a come un 
intent venga caratterizzato anche da un campo di nome data oltre a quello relativo all' 'action e alla 
category. E un'informazione che caratterizza un particolare intent filler attraverso una definizione del 
tipo: 

<data android : host=" string" 

android : mimeType=" string" 
android : path=" string" 
android : pathPattern=" string" 
android : pathPref ix=" string" 
android : port=" string" 
android : scheme=" string" /> 

Per questo campo esistono alcune regole che descriviamo di seguito. 

• Nel caso in cui un oggetto intent non contenga informazioni relative a un URI o al relativo 
mime-type, il componente verrà selezionato solamente se nel corrispondente <intent- 

f iiter/> non si specifica alcuna informazione relativamente ai dati 

• Nel caso in cui un intent contenga la definizione di un URI e il corrispondente mime-type non 
sia noto, il componente verrà selezionato solamente se le informazioni specificate in <data/> 
corrispondono a quelle dell'URI. 

• Se un intent contiene le informazioni relative al solo mìme-type e non quelle relative a un URI, il 
componente viene scelto solo se il corrispondente <data/> specifica lo stesso mime-type e non 
fornisce informazioni relativamente all'URI. 
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• Infine, nel caso in cui l'intent contenga le informazioni relative all'URI e al mime-t ype, perché 
specificato o dedotto dal content provider corrispondente, il particolare componente verrà 
scelto se il <data/> relativo contiene lo stesso mime-type e se, per quello che riguarda FURI, 
definisce degli attributi concordi all'URI dell' intent. In quest'ultimo caso esiste un'eccezione 
relativa all'utilizzo degli schemi content : e file : per i quali FURI non assume importanza. 

Queste sono regole che è bene valutare di volta in volta e che contemplano moltissimi casi che 
sarebbe impossibile approfondire in questa sede e per i quali rimandiamo alla documentazione 
ufficiale. Quello che è invece importante sottolineare è che se un URI è del tipo content : / / allora fa 
riferimento a un content provider tra le cui responsabilità vi è quella di ritornare il corrispondente 
mime-type. In accordo con quella che è la RFC-2046, ciascun mime-type si compone di due parti 
che possiamo chiamare type e subtype. Pensiamo, per esempio al classico mime-type text/htmi 
associato a una pagina HTML o a quello application/pdf associato a un documento PDF. Vediamo 
come la prima parte sia un'espressione del tipo di contenuto, mentre la seconda, che dipende dalla 
prima, sia una descrizione della modalità con cui il dato viene rappresentato. Si tratta di informazioni 
gestite in modo standard da un ente che si chiama LANA (Internet Assigned Numbers Authority). 
Nel caso dei content provider non si tratta però, come dimostra il nostro caso, sempre di informazioni 
di tipo standard. In questi casi, le RFC consentono di definire delle rappresentazioni personalizzate 
attraverso particolari subtype. Alcuni di questi sono riservati e caratterizzati dal prefisso . vnd. Un 
esempio è quello dei mime-type di Microsoft Office, dove ai documenti PowerPoint è associato 
appiication/vnd.ms-powerpoint. Altro esempio è quello dei documenti XUL di Mozilla, 
rappresentati dal valore appiication/vnd.moziiia.xui+xmi. Sono quindi rappresentazioni 
personalizzate registrate allo LANA come riservate. Altre sono invece completamente personalizzabili 
e caratterizzate da un subtype del tipo x-. Un esempio su tutti è quello relativo ai file con estensione 

.tar a Cui viene associato il mime-type application/x-tar. Nel CaSO dei COntent provider i mime- 
type sono di due tipi e permettono di individuare un elenco di risorse attraverso un valore del tipo 

vnd . android . cu r sor . dir /vnd . <custom dell ' applìcazione> 

oppure una risorsa singola con il valore 

vnd. android . cu r sor . item/vnd . <custom dell ' applicazione> 

Notiamo come siano valori il cui type è riservato, mentre il subtype è definito solo per la prima 
parte. Nel caso della base dati relativa alla nostra applicazione potremmo impostare 

vnd. android. cursor . dir /vnd . horovote 

come mime-type identificativo dell'elenco, e quindi con 

vnd . android .cursor . item/ vnd . horovote 

cioè il mime-type associato alla singola informazione. Si tratta di informazioni che aggiungiamo alla 
nostra classe di metadati così come avviene per i content provider standard dell'applicazione. La 
classe ughoDB diventa la seguente: 

public final class UghoDB { 

public static final String DB_NAME = "UghoDB"; 
public static final int DB_VERSION = 1; 

public static final String AUTHORITY = "uk . co .massimocarli . android. ugno" ; 

private UghoDB () { 

} 
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public static class HoroVote implements BaseColumns { 



public static final String TABLE_NAME = "HORO_VOTE"; 
public static final String PATH = "horovote"; 

public static final Uri CONTENT_URI = Uri .parse (ContentResolver . SCHEME_CONTENT 
+ "://" + AUTHORITY + "/" + PATH); 

public static final String MIME_TYPE_D IR = 

ContentResolver. CURSOR_DIR_BASE_TYPE + " /vnd. horovote " ; 

public static final String MIME_TYPE_ITEM 

= ContentResolver. CURSOR_ITEM_BASE_TYPE + " /vnd . horovote " ; 

public static final String ENTRY_DATE = "entry_date" ; 

public static final String LOVE_VOTE = "love_vote"; 

public static final String HEALTH_VOTE = "health_vote" ; 

public static final String WORK_VOTE = "work_vote" ; 

public static final String LUCK_VOTE = "luck_vote"; 

public static final String HORO_SIGN = "horo_sign"; 

public static final String LOCATION = "location"; 

} 

} 

La costante authority è caratteristica del content provider, per cui è stata definita nella classe 
esterna e poi utilizzata nelle classi interne (nel nostro caso solo una) per la definizione deimìme-type 
relativi all'elenco e all'elemento singolo. Vediamo come sia stata definita anche una costante path che 
abbiamo poi utilizzato nella definizione della costante content_uri di tipo uri. Si tratta di una 
costante che è bene fornire per ciascuna delle risorse gestite, in quanto permette la composizione 
veloce di eventuali altri URI durante l'esecuzione delle query. Ricordiamo poi come la classe interna 
HoroVote implementi l'interfaccia standard BaseColumns da cui eredita la colonna di nome _id. 

Implementazione di un content provider 

La definizione dei metadati è solamente il primo passo nella realizzazione di un content provider che 
altro non è che una particolare specializzazione dell'omonima classe del package android. content, di 
cui andremo a implementare una serie di metodi astratti Per la nostra applicazione abbiamo quindi 
definito la classe HoroContentProvìder iniziando dal seguente metodo: 

public abstract boolean onCreateO 

il quale viene invocato al momento dell'avvio del content provider e ha una responsabilità molto 
chiara, ovvero quella di creare la base per la memorizzazione delle informazioni che nel nostro caso 
sono contenute all'interno di un database SQLite. 

NOTA 

Sebbene la maggior parte delle implementazioni di un content provider faccia riferimento a 
informazioni memorizzate all'interno di un database SQLite, quella descritta è solo una delle 
alternative. Potremmo infatti rendere possibile l'accesso a informazioni memorizzate su file system, 
in memoria o remote attraverso una stessa interfaccia. 

Nella nostra implementazione abbiamo utilizzato una nostra implementazione di fcQLiteOpenHeiper 
che abbiamo chiamato HoroOpenHeiper, il cui codice, ormai molto semplice, è il seguente: 
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public class HoroOpenHelper extends SQLiteOpenHelper { 

private Context mContext; 

public HoroOpenHelper (Context context) { 

super (context, UghoDB . DB_NAME , nuli, UghoDB . DB_VERSION) ; 
this .mContext = context; 

} 

SOverride 

public void onCreate (SQLiteDatabase sqLiteDatabase) { 
try { 

sqLiteDatabase .beginTransaction ( ) ; 

final String createSql = ResourceUtils 

. getRawAs String (mContext , R.raw. create_schema) ; 

sqLiteDatabase . execSQL (createSql) ; 

sqLiteDatabase . setTransactionSuccessful () ; 
} catch (Exception e) { 

e .printStackTrace ( ) ; 
} finally { 

sqLiteDatabase . endTransaction ( ) ; 

} 

} 

SOverride 

public void onUpgr ade (SQLiteDatabase sqLiteDatabase, int i, ìnt i2) { 
try { 

sqLiteDatabase .beginTransaction () ; 

final String dropSql = ResourceUtils 

. getRawAsString (mContext , R . raw . drop_schema) ; 

sqLiteDatabase . execSQL (dropSql) ; 

sqLiteDatabase . setTransactionSuccessful () ; 
} catch (Exception e) { 

e .printStackTrace ( ) ; 
} finally { 

sqLiteDatabase . endTransaction ( ) ; 

} 

onCreate (sqLiteDatabase) ; 

} 

} 

Da notare solamente come sia stato implementato il costruttore attraverso l'utilizzo delle costanti 
definite nella classe dei metadati Le operazioni eseguite in corrispondenza della creazione ed 
eventuale aggiornamento non hanno ormai nulla di particolare se non l'utilizzo delle transazioni per 
ottimizzarne le performance. Il metodo oncreateo del nostro content provider diventa questo: 

@Override 

public boolean onCreate () { 

dbHelper = new HoroOpenHelper (getContext ()) ; 
return true; 

} 

Abbiamo più volte sottolineato come una delle principali responsabilità di un content provider sia 
quella di saper associare un URI almime-type delle informazioni collegate, operazione utile 
soprattutto in fase di intent resolution Questa responsabilità si riflette nell'implementazione 
dell'operazione 

public abstract String getType (Uri uri) 

che ritorna appunto ilmime-type associato all'URI passato come parametro. È facile intuire come 
in questa fase sia importante disporre di un meccanismo che ci permetta di riconoscere facilmente i 
diversi URI passati come parametro. Nel nostro caso il content provider gestisce solo un tipo di 
risorse associato, oltre che all'authority, al particolare percorso che può essere del tipo /horovote, 
nel caso di un elenco di valori, o /horoteam/<id> nel caso di un valore specifico. Potremmo avere 
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anche altri percorsi relativi ad altre informazioni all'interno dello stesso provider. A tale scopo Andro id 
mette a disposizione la classe di utilità uriMatcher, che consente appunto di riconoscere in maniera 
efficiente le tipologie di URI che un content provider può gestire. In poche parole si tratta di un 
meccanismo che permette di associare dei valori numerici a un insieme di pattern che un particolare 
URI può soddisfare. Il suo utilizzo avviene in due passi. Il primo è quello di creazione dell'istanza di 
uriMatcher e dell' associazione dei valori numerici ai possibili pattern che un URI può soddisfare. Un 
esempio è proprio relativo al nostro caso, dove si ha l'inizializzazione di un'istanza dello uriMatcher 
nel seguente modo: 

private final static UriMatcher URI_MATCHER = new UriMatcher (UriMatcher .NO_MATCH) ; 
private final static int HORO_DIR_INDICATOR = 1; 
private final static int HORO_I TEM_I ND I C ATOR = 2 ; 

static { 

URI_MATCHER . addURI (UghoDB . AUTHORITY, UghoDB . HoroVote . PATH, HORO_DIR_INDICATOR) ; 

URI_MATCHER . addURI (UghoDB . AUTHORITY, UghoDB . HoroVote . PATH + "/#", 
HORO_I TEM_IND I CATOR) ; 
} 

Innanzitutto viene creata un'istanza dello uriMatcher a cui viene passata la sua costante no_match, 
che è il valore che lo stesso oggetto ritornerà nel caso in cui venisse confrontato un URI che non 
soddisfa alcuna delle regole registrate. Di seguito, attraverso un inizializzatore statico, abbiamo 
associato a ogni pattern un valore numerico definito attraverso delle costanti intere. In sintesi, nel caso 
in cui TURI fosse del tipo 

content : //uk . co . massìmocarlì . android . ugho/horovote/2 3 

il valore ritornato dal uriMatcher dovrà essere quello associato alla costante 
horo_item_[ndi cator. Il confronto avviene poi attraverso il metodo 

public int match (Uri uri) 

È un meccanismo per incapsulare all'interno di un unico oggetto le logiche di confronto tra i diversi 
URI che un content provider riceve come parametri delle proprie operazioni. In questo modo è quindi 
possibile gestire i vari casi attraverso un semplice switch piuttosto che attraverso una successione di 

blocchi if/else/ìf . 

Con l'inizializzazione dell' uriMatcher e la definizione delle costanti nelle classi relative ai metadati, 
il metodo getType ( ) responsabile di ritornare il mime-type corrispondente a un determinato URI 
diventa a questo punto banale, ovvero: 

SOverride 

public String getType ( final Uri uri) { 
switch (URI_MATCHER. match (uri) ) { 
case HORO_DIR_INDICATOR: 

return UghoDB . HoroVote . M I ME_T YP E_D IR; 
case HORO_I TEM_IND I CATOR : 

return UghoDB . HoroVote . MIME_TYPE_ITEM; 
default : 

throw new IllegalArgumentException ( "The Uri " + uri + 

" is unknown for thìs ContentProvider " ) ; 

} 

} 

Esso si traduce infatti in un semplice switch che ritorna i valori delle costanti definite dai metadati in 
corrispondenza del tipo di URI passato come parametro di input. Nel caso in cui L'URI non sia 
compatibile con il content provider genereremo un'eccezione di tipo IllegalArgumentException. 

L'operazione più importante tra quelle esposte da un content provider è sicuramente quella di 
query, che sappiamo essere associata a una specie di select. L'operazione da implementare è la 
seguente: 
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public abstract Cursor query (Uri uri, Stringi] projection, 

String selection, String[] selectionArgs, String sortOrder) 

che ha tra i propri parametri un URI identificativo della risorsa da estrarre, un parametro chiamato 
projection che rappresenta l'insieme dei campi da estrarre, una selection relativa alla gestione della 
clausola where con i valori corrispondenti e infine un'opzione relativa alla modalità di ordinamento. 
Come nel caso del metodo getType o , anche qui il risultato e la particolare operazione da eseguire 
dipenderanno dal tipo di URI e dalle informazioni relative alle s election. Se si tratta di un URI 
relativo a un elenco dovremo semplicemente estrarre tutti i record. Se invece è un URI che identifica 
un preciso elemento, dovremo estrarre da esso le informazioni relative all'id per poterlo utilizzare 
come selection. Vediamo poi come il risultato sia un riferimento a un'implementazione 
dell'interfaccia cursor come nel caso di accesso al DB. Il tipo di ritorno delle operazioni di un content 
provider è la principale ragione per cui nella maggior parte dei casi viene implementato attraverso 
l'utilizzo di un database. Senza addentrarci in troppi dettagli, F implementazione del metodo di 
query ( ) relativa al nostro content provider è la seguente: 

@Override 

public Cursor query (Uri uri, Stringi] projection, String selection, 
Stringi] selectionArgs, String sortOrder) { 
final int uriMatcherCode = URI_MATCHER. match (uri) ; 
Cursor cursor = nuli; 
String itemld = nuli; 
StringBuilder whereClause = nuli; 

SQLiteDatabase db = dbHelper . getReadableDatabase ( ) ; 
switch (uriMatcherCode) { 

case HORO_I TEM_IND I CATOR : 

itemld = uri . getPathSegments () .get (1) ; 

whereClause = new StringBuilder (UghoDB . HoroVote ._ID) 

.appende = "). append (itemld) ; 
if (selection != nuli) { 

whereClause . append ( " AND ("). append ( selection) . append ( " ) "); 

} 

cursor = db . query (UghoDB . HoroVote . TABLE_NAME, nuli, 

whereClause .toString () , selectionArgs, 
nuli, nuli, nuli) ; 

break; 

case HORO_DIR_INDICATOR: 

cursor = db . query (UghoDB . HoroVote . TABLE_NAME, nuli, 

selection, selectionArgs, nuli, nuli, nuli) ; 

break; 

} 

if (cursor != nuli) { 

cursor. setNotif icationUri (getContext () . getContentResolver () , 
UghoDB. HoroVote. CONTENT_URI) ; 

} 

return cursor; 

} 

Una volta riconosciuto il particolare tipo di URI non facciamo altro che utilizzare o meno 
rinformazione relativa all'id come ulteriore filtro. La stessa classe uri contiene infatti diversi metodi di 
utilità che ci permettono di estrarre le diverse parti che lo compongono. Attraverso il metodo 
getPathSegments ( ) otteniamo infatti le diverse componenti del percorso, tra cui Pid che si trova in 
posizione 1 . Molto importante è invece la parte evidenziata alla fine del metodo, che consiste 
nell'invocazione del metodo letNotificationuri o sulcursor. Si tratta infatti del meccanismo a 
nostra disposizione per notificare agli oggetti interessati che le informazioni contenute nel cursore sono 
cambiate. Il parametro ci consente di informare il content resolver della modifica delle informazioni 
associate all'URI del tipo UghoDB . HoroVote . content_uri . Ma cos'è il content resolver! Essendo un 
componente che può essere in esecuzione in applicazioni diverse e quindi in processi diversi, un 
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content provider non è direttamente accessibile e necessita di un ulteriore strumento che è 
rappresentato proprio dal content resolver il cui riferimento si ottiene dal Context attraverso il 

metodo getContentResolver ( ) . 

Un'altra interessante operazione offerta dal content provider è quella che permette rinserimento di 
un dato attraverso F implementazione del metodo 

public abstract Uri insert (Uri uri, ContentValues values) 

È importante notare la presenza di un parametro di tipo uri, il quale però dovrà essere relativo 
all'elenco di informazioni. L'oggetto contentvaiues dovrà invece contenere le informazioni da inserire 
come fatto nel caso dell'accesso al DB visto in precedenza. Vediamo poi come il valore di ritorno sia 
FURI relativo alla nuova informazione inserita. Nel nostro caso il codice utilizzato è il seguente: 

SOverride 

public Uri insert (Uri uri, ContentValues content Values ) { 
if (URI_MATCHER. match (uri) == HORO_DIR_INDICATOR) { 

SQLiteDatabase db = dbHelper . getWritableDatabase ( ) ; 
long newTeamld = db . insert (UghoDB . HoroVote . TABLE_NAME, 

UghoDB . HoroVote . LOCATION, ContentValues ) ; 

if (newTeamld > 0) { 

Uri newTeamUri = ContentUris . withAppendedld ( 

UghoDB . HoroVote . CONTENT_URI , newTeamld) ; 
getContext () . getContentResolver ( ) . notifyChange (newTeamUri, nuli) ; 

return newTeamUri; 

} 

} else { 

throw new IllegalArgumentException ( "The Uri " + uri + 

" is unknown for this ContentProvider " ) ; 

} 

return nuli; 

} 

Osserviamo innanzitutto come FURI da utilizzare nel caso di un inserimento debba necessariamente 
essere relativo a un insieme di risorse. Dopo aver ottenuto il riferimento al DB in scrittura attraverso il 
metodo getWritableDatabase 0 dell'oggetto sqiiteOpenHeiper, ne utilizziamo il metodo i nsert, li 
quale ha la stessa firma già vista. Altro aspetto da osservare riguarda il valore di ritomo, che dovrà 
essere FURI dell'oggetto appena inserito. Per comporre tale valore abbiamo utilizzato il metodo 
statico withAppendedld o della classe di utilità contenturis. Infine è stato utilizzato il metodo 
notifyChange ( ) del content resorver per la notifica di una variazione della base dati in corrispondenza 
della quale gli oggetti interessati si possono aggiornare. 

L'operazione forse più complessa è quella relativa all'aggiornamento, che viene implementata 
attraverso il metodo 

public abstract int update (Uri uri, ContentValues values, String selection, 
Stringi] selectionArgs ) 

Essa consente di aggiornare, coni valori contenuti nel parametro values, i record individuati 
attraverso le selection. Il valore di ritorno rappresenta, come spesso accade nelle operazioni di 
update, il numero di record aggiornati Nel nostro caso il metodo, molto simile a quello diquery, è 
questo: 

@Override 

public int update (Uri uri, ContentValues ContentValues, String selection, 
Stringi] selectionArgs) { 
String itemld = nuli; 
StringBuilder whereClause = nuli; 

SQLiteDatabase db = dbHelper . getWritableDatabase () ; 
int updateNumber = 0; 
switch (URI_MATCHER. match (uri) ) { 
case HORO_I TEM_IND I CATOR : 

itemld = uri . getPathSegments ( ) . get ( 1 ) ; 
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whereClause = new StringBuilder (UghoDB . HoroVote ._ID) 

.appendi" = " ) . append (itemld) ; 
if (selection != nuli) { 

whereClause . append ( " AND ("). append ( selection) . append ( " ) "); 

} 

updateNumber = db . update (UghoDB . HoroVote . TABLE_NAME, 

contentValues , whereClause . toString () , selectionArgs); 

break; 

case HORO_DIR_INDICATOR: 

updateNumber = db . update (UghoDB . HoroVote . TABLE_NAME, 

contentValues, selection, selectionArgs) ; 

break; 

} 

if (updateNumber > 0) { 

getContext() . getContentResolver ( ) . noti fyChange (uri, nuli) ; 

} 

return updateNumber; 

} 

Anche qui l'eventuale id presente nell'UPJ viene utilizzato come ulteriore filtro per la selezione dei 
record da aggiornare. 

Per completare le funzionalità di CRUD non ci resta che implementare la seguente operazione: 

public abstract int delete (Uri uri, String selection, String[] selectionArgs) 

che permette appunto la cancellazione delle informazioni associate all'UPJ passato come 
parametro, eventualmente filtrate attraverso le selection. È semplice intuire come si tratti di un 
metodo molto simile al precedente, che utilizza l'operazione dideiete o al posto di quella di 

update () , OWerO 
dOverride 

public int delete (Uri uri, String selection, Stringi] selectionArgs) { 
String itemld = nuli; 
StringBuilder whereClause = nuli; 

SQLiteDatabase db = dbHelper . getWritableDatabase ( ) ; 
int deleteNumber = 0; 
switch (URI_MATCHER. match (uri) ) { 
case HORO_I TEM_IND I CATOR : 

itemld = uri . getPathSegments () . get (1) ; 

whereClause = new StringBuilder (UghoDB . HoroVote ._ID) 

.appende = "). append (itemld) ; 
if (selection != nuli) { 

whereClause . append ( " AND ("). append ( selection) . append ( " ) "); 

} 

deleteNumber = db . delete (UghoDB . HoroVote . TABLE_NAME, 

whereClause .toString ( ) , selectionArgs) ; 

break; 

case HORO_DIR_INDICATOR: 

deleteNumber = db . delete (UghoDB . HoroVote . TABLE_NAME, 
selection, selectionArgs) ; 

break; 

} 

if (deleteNumber > 0) { 

getContext() . getContentResolver ( ) . noti fyChange (uri, nuli) ; 

} 

return deleteNumber; 

} 

Come nel caso dell' update, ci sono istruzioni (evidenziate) che permettono di notificare la modifica 
delle informazioni associate a un particolare URI. I valori di ritorno sono rispettivamente il numero di 
elementi aggiornati e cancellati. 

Per poter utilizzare il nostro content provider è necessario poterlo registrare all'interno del file di 
configurazione AndroidManif est . xml. Per fare questo è sufficiente utilizzare il componente 
< P rovider/> nel seguente modo: 

<provider 
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android: name=" . content . HoroContentProvider " 

android: authorities="uk . co .massimocarli .android . ugho" / > 

dove notiamo l'utilizzo degli attributi android: name e android : authorities per l'associazione delle 
informazioni corrispondenti Abbiamo così definito un content provider che ci consentirà di interagire 
con il nostro DB attraverso un'interfaccia standard tipica dei servizi REST, come vedremo nel 
prossimo paragrafo. 

Utilizzo di un content provider 

Dopo aver descritto nel dettaglio le responsabilità di un content provider ci occupiamo degli 
strumenti che Android ci offre per potervi accedere. Come più volte ricordato, la modalità di accesso 
prevede la definizione di particolari URI per l'identificazione di risorse singole o multiple. Per 
definizione un content provider è una risorsa condivisa tra applicazioni diverse; questo introduce 
problematiche di consistenza delle informazioni, che fortunatamente ci vengono risparmiate da 
particolari API che andiamo a descrivere, prima fra tutte la classe contentResoiver, a cui abbiamo 
già accennato. Ci permette di accedere alle informazioni di un content provider senza sapere 
esattamente quale sia ma semplicemente passando un URI come parametro alle diverse operazioni 
Come dimostrazione di questo abbiamo creato la classe contentLocaiDataFragment, che utilizza il 
content provider al posto del DAO utilizzato in precedenza: 

public class ContentLocalDataFragment extends SherlockLìstFragment { 
/ / Come prima 
private Cursor mCursor; 

SOverride 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, 

Bundle savedlnstanceState) { 
View customLayout = inflater . inf late (R . layout . activity_list_layout , nuli) ; 
return customLayout; 

} 

@SuppressWarnings ( "deprecation" ) 
@Override 

public void onStartO { 
super . onStart ( ) ; 

mCursor = getActivity ( ) . getContentResolver ( ) 

. query (UghoDB . HoroVote . CONTENT_URI , nuli, nuli, nuli, nuli); 
getActivity () . startManagingCursor (mCursor) ; 

mAdapter = new SimpleCursorAdapter (getActivity () , 

R . layout . custom_list_item, mCursor, FROM, TO) ; 
mAdapter . setViewBinder (new SimpleCursorAdapter .ViewBinder ( ) { 
SOverride 

public boolean setViewValue (View view, Cursor cursor, int i) { 
final TextView outputTextView = (TextView) view; 
final LocalDataModel model = LocalDataModel . fromCursor (cursor) ; 

switch (view . getld ( ) ) { 

case R. id. list_item_date : 

outputTextView . setText (DATE_FORMAT . format (model . entryDate) ) ; 
break; 

case R. id. list_item_love_vote : 

outputTextView . setText (getResources ( ) 

. getString (R. string . love_value_pattern, model . loveVote) ) ; 
break; 

case R. id. list_item_health_vote : 

outputTextView . setText (getResources ( ) 

. getString (R . string . health_value_pattern, 

model. healthVote) ) ; 

break; 

case R. id. list_item_work_vote : 
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outputTextView . setText (getResources ( ) 

.getString (R. string . work_value_pattern, 
model .workVote) ) ; 

break; 

case R. id. list_item_luck_vote : 

outputTextView . setText (getResources ( ) 

. getString (R. string . luck_value_pattern, 
model . luckVote) ) ; 

break; 

} 

return true; 

} 

}) ; 

setListAdapter (mAdapter) ; 

} 

} 

Relativamente all'utilizzo del content provider nel modo descritto è bene tare alcune considerazioni. 
La prima è che la query è stata eseguita attraverso l'oggetto di tipo content resolver ottenuta dal 
Context. L'aspetto più importante riguarda poi l'utilizzo del metodo startManagingCursor ( ) , 
un'utility per agganciare il ciclo di vita dell'oggetto cursor a quello dell' activity (o fragment) nel quale 
il cursore stesso è definito. In sintesi invoca automaticamente il metodo deactivate ( ) sul cursor in 
corrispondenza del metodo onstop ( ) e quindi il metodo ciose ( ) in corrispondenza del metodo 
onDestroy ( ) del componente contenitore. Molto utile è anche il fatto che, in caso di scenari come 
quello della rotazione del dispositivo, il cursore venga comunque riavviato con la nuova esecuzione 
della relativa query. 

Un lettore attento si accorgerà che è un meccanismo che è stato deprecato a partire dalla versione 
1 1 della piattaforma, nella quale sono stati introdotti quelli che si chiamano loader e che vedremo nel 
dettaglio nel prossimo capitolo dedicato al multithreading. Il problema principale che ha portato alla 
deprecation è legato al fatto che le query, o comunque le operazioni di accesso al DB, vengono 
eseguite nelthread principale dell'applicazione, il quale dovrebbe invece occuparsi della sola 
renderizzazione. L'esecuzione di query nel thread principale portava spesso a problemi diANR 
{Application Not Responding), per cui si è deciso di introdurre un meccanismo asincrono di accesso 
ai dati (e in particolar modo a quelli all'interno di un content provider) che si chiama appunto 
Loader s, accessibile grazie alla Compatibility Library dalle versioni di API Level precedenti la 11. 

Dal punto divista funzionale lasciamo al lettore la verifica sul risultato visualizzato, che è 
esattamente quello delle implementazioni precedenti. 

I content provider di Android 

A questo punto l'utilizzo di uno dei content provider di Android risulta molto semplice non appena 
sono noti i corrispondenti URI e la tipologia delle informazioni in essi contenuti Sono informazioni che 
il lettore può trovare all'interno della documentazione relativa al package android. provider e che 
sono rappresentate da un insieme di costanti relative ai diversi URI per l'interrogazione. Supponiamo 
per esempio di voler accedere ai contatti del dispositivo. Per questo esiste la classe 
contactscontract .contacts, che contiene tra le sue costanti quella di nome content_uri, che ci 
permette di accedere a tutte le informazioni analogamente a quanto abbiamo fatto con il nostro 
provider. Sempre osservando la documentazione notiamo come si tratti di una classe che implementa 
una serie di interfacce tra cui la contactscontract .contactscoiumns, che elenca l'insieme delle 
informazioni che è possibile trovare all'interno dei contatti Rileviamo infatti la presenza delle 
informazioni relative a display_name, photo_id e altro ancora. Lasciamo al lettore come esercizio la 
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lettura delle informazioni relative ad alcuni dei content provider di Andro id facendo attenzione che 
alcune query richiedono comunque dei permessi per l'interrogazioni. 

Conclusioni 

In questo capitolo abbiamo finalmente affrontato tutti gli aspetti relativi alla gestione dei dati in 
Android. Abbiamo iniziato con la descrizione delle preferenze, ovvero di quel framework per la 
memorizzazione e la modifica di informazioni da associate alle singole applicazioni Siamo poi passati 
alla gestione dei file verificando come si tratti di API molto simili a quelle standard di Java. Molto 
interessante è stata invece la discussione relativamente all'utilizzo di un database locale che in Android 
è realizzato con SQLite, di cui abbiamo studiato le principali caratteristiche e strumenti Abbiamo poi 
descritto in grande dettaglio come è possibile condividere delle informazioni che nel caso dei DB 
SQLite sono private di ogni applicazione, tra più componenti. Abbiamo infine studiato i content 
provider realizzandone un'implementazione personalizzata. Nel prossimo capitolo descriveremo un 
altro importantissimo insieme di API che ci permetteranno di gestire nel migliore dei modi delle attività 
in background secondo diverse modalità. 
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Capitolo 9 



Multithreading e servizi 



Dopo aver esaminato nel dettaglio F architettura di Android relativamente alla gestione 
dell'interfaccia grafica e della persistenza delle informazioni, in questo capitolo ci occupiamo di altri 
due aspetti fondamentali: il multithreading e i servizi Abbiamo infatti visto come il dispositivo debba 
garantire un elevato grado di interazione con l'utente. E quindi necessario che l'esecuzione di 
operazioni "pesanti" non influenzi quella che è la gestione dell'interfaccia grafica. Questo si traduce nel 
fatto che la gestione degli eventi e delle informazioni visualizzate nel display debbano avvenire in 
processi, o meglio thread, separati. Dopo un'introduzione sui concetti base della programmazione 
concorrente in Java, ci occuperemo di handler e looper, ovvero del meccanismo che consente a 
un'applicazione di interagire con il thread responsabile della gestione grafica a cui abbiamo già 
accennato precedentemente. Vedremo poi quello che chiama Notification Service, che permetterà a 
un servizio in background di comunicare delle informazioni all'utente. La seconda parte del capitolo 
sarà invece dedicata all'utilizzo e implementazione dei service, che permettono l'esecuzione in 
background di particolari operazioni private di un' app Reazione o condivise tra più processi 
Passeremo poi alla descrizione dei BroadcastReceiver, cioè di quei componenti che si attivano in 
corrispondenza della ricezione di un particolare intent lanciato secondo la modalità broadcast. 
Concluderemo infine il capitolo descrivendo iloader, che sono stati introdotti in Android 3.0 e che 
consentono di risolvere i problemi a cui abbiamo accennato nel Capitolo 8 dovuti all'accesso alla 
base dati all'interno del thread principale. 

Thread: concetti base 

Osservando le API di Android possiamo notare come siano presenti non solo le normali classi per 
la realizzazione di thread ma anche le Concurrent API introdotte in Java dalla versione 1 .4. Qui non 
ci occuperemo di concetti avanzati di programmazione concorrente, per i quali rimandiamo alla 
documentazione ufficiale di Sun/Oracle, ma di quelli che sono i principali meccanismi utilizzati dalle 
applicazioni Android per l'esecuzione di attività in background. Per descrivere cos'è un thread 
{thread of control) possiamo partire da lontano definendo un algoritmo come un insieme di 
operazioni spesso descritte con linguaggio naturale, che permettono la risoluzione di un particolare 
problema. 

NOTA 

Il thread of control si può paragonare all'insieme dei fili che si usano per muovere le varie parti di 
una marionetta. Gestisce infatti in modo indipendente parti diverse di uno stesso oggetto. 

Un algoritmo può essere scritto utilizzando diversi linguaggi di programmazione dando origine a 
quelli che si chiamano programmi. Per esempio, l'algoritmo del Quick Sort per l'ordinamento può 
essere implementato in Java, in C++, in Fortran e così via. Molto più importante è comunque il 
concetto di processo, ovvero di esecuzione di un particolare programma. Due processi esecuzione di 
uno stesso programma, sono caratterizzati dal fatto di utilizzare ciascuno una propria area di memoria 

372 



e quindi si possono considerare indipendenti uno dall'altro anche se in esecuzione nello stesso 
momento (almeno apparentemente). In diversi ambiti può essere utile estendere il concetto di 
"esecuzione simultanea" anche alle diverse parti di una stessa applicazione. Pensiamo per esempio al 
caso in cui si avesse la necessità di leggere delle informazioni da uno stream, operazione che 
sappiamo essere bloccante nel caso di mancanza di informazionL Al fine di non interrompere l'intera 
applicazione, è bene che l'attività di lettura dallo stream avvenga inunthread diverso da quello di 
gestione, per esempio, della GUI. 

In questo caso non si parla di processo ma di thread, il quale è caratterizzato dal fatto di 
condividere con altri delle stesse locazioni di memoria richiedendo degli strumenti che consentano di 
mantenere l'integrità dei dati condivisi Java è un linguaggio nativamente multithreading, in quanto 
mette a disposizione di ogni oggetto, attraverso la classe ob ject, quelli che sono i tipici strumenti di 
sincronizzazione, ovvero i metodi wait o e notìfy o , oltre a disporre del noto costrutto 

synchronized. 

La creazione di un normale thread in Andro id non si discosta di molto da quello che avviene in Java 
standard. Anche qui è possibile utilizzare due modi diversi; 

• estendere la classe Threadl 

• implementare l'interfaccia Runnable. 

Nel primo caso è sufficiente estendere la classe Thread facendo Yoverride del metodo run ( ) , che 
contiene la logica relativa alle operazioni che dovranno essere eseguite in modo concorrente in 
corrispondenza dell' esecuzione del metodo start o . 

NOTA 

Un errore molto comune consiste nel pensare che il metodo ™o possa essere invocato 

direttamente. Nessuno vieta di invocare un metodo pubblico di un oggetto, ma è bene ricordare che 
in questo caso esso verrebbe eseguito nel thread del chiamante e quindi non all'interno di un nuovo 
thread. Il modo corretto, e unico, è quello di invocare il metodo start o. 

A tal proposito è bene ricordare come un thread termini la propria esecuzione nel momento in cui il 
metodo run o giunge a completamento, in quanto il metodo stop o è stato da tempo deprecato. 
Terminata l'esecuzione, un thread diventa una normale istanza, che può mantenere il proprio stato, 
eseguire delle operazioni ma non potrà più essere riavviata attraverso una nuova esecuzione di 
start ( ) , per la quale si rende necessaria la creazione di un nuovo oggetto: 

public class MyThread extends Thread { 

private boolean running = false; 

public MyThread () { 

super ( "MyThread" ) ; 

} 

public void start (){ 
running = true; 
super . start ( ) ; 

} 

SOverride 

public void run ( ) { 
while (running) { 

/ / Corpo del thread 

} 

} 

public void stopThread ( ) { 
running = false; 
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} 

} 

Nel listato precedente vediamo la presenza di un costruttore, sebbene non sia necessario, che 
richiama quello della classe Thread passando una String utile in làse di debug per riconoscere il 
thread tra altri. Il corpo del thread, ovvero le operazioni da eseguire in modo concorrente, vengono 
implementate all'interno del metodo run ( ) . 

Rileviamo poi l'utilizzo della variabile booleana di nome running, che ci serve per interrompere 
l'esecuzione del metodo run ( ) facendo terminare il ciclo whiie solitamente presente in oggetti di 
questo tipo. L'ereditarietà, specialmente in Java, è comunque un livello troppo forte di dipendenza. Se 
la classe che contiene la logica da eseguire in modo concorrente estendesse già una particolare classe, 
la mancanza dell'ereditarietà multipla delle classi ci impedisce di estendere anche la classe Thread. 
Per questo motivo il secondo meccanismo utilizzato per la creazione di un thread consiste nella 
creazione di un' istanza della classe Thread a cui viene però passata un'implementazione 
dell'interfaccia Runnab le, che descrive proprio l'unica operazione che interessa: 

public abstract void run() 

È possibile creare un'istanza della classe Thread nel modo descritto da questo codice: 

public class MyRunnableThread implements Runnable { 

private Thread thread; 

private boolean running; 

public void run ( ) { 
while ( running) { 

// Corpo del thread 

} 

} 

public void start (){ 
if ( ! running) { 

running = true; 

thread = new Thread (this, " MyRunnableThread"); 
thread. start () ; 

} 

} 

public void stop(){ 
if (running) { 

running = false; 
thread = nuli; 

} 

} 

} 

Notiamo come l'implementazione dei metodi start ( ) e stop ( ) (non sono quelli di Thread in 
quanto definiti nella nostra classe) permetta alla stessa istanza di essere riavviata più volte. Essa infatti 
nasconde il fatto di realizzare a ogni start ( ) una nuova istanza della classe Thread attraverso un 
costruttore che prevede come parametro il riferimento all'oggetto Runnable di cui eseguire il metodo 
run < ) . Al costruttore del tipo 

public Thread (Runnable runnable) 

si può passare il riferimento a una qualunque classe purché implementi l'interfaccia Runnable. 
Da questo punto di vista, quindi, la realizzazione di un thread in Android non si discosta di molto da 
quello che avviene in ambiente Java standard. In questo ambiente dobbiamo però considerare diversi 
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aspetti, tra cui il fatto che i thread di questo tipo sono i primi a essere eliminati dall'ambiente quando 
servono risorse. Nel caso in cui si avesse la necessità di eseguire delle operazioni in background per 
lungo tempo, Android mette a disposizione i servìce, ovvero componenti per i quali l'ambiente riserva 
un trattamento e un ciclo di vita particolare che esamineremo nel dettaglio più avanti. Un secondo 
aspetto molto importante riguarda il fatto che spesso i thread di un'applicazione vengono utilizzati per 
accedere a risorse esterne per l'acquisizione di informazioni che poi dovranno essere visualizzate 
attraverso la UI o comunque interagire con essa. Serve allora un meccanismo che consenta l'invio di 
informazioni alla UI senza impattare quella che è la responsiveness; questo sarà l'argomento del 
prossimo paragrafo. 

Handler e looper 

Nel paragrafo precedente abbiamo visto come la creazione di un thread sia un'operazione molto 
semplice anche in Android. I problemi si hanno però quando si tratta di thread con la responsabilità di 
procurare delle informazioni da visualizzare all'interno di componenti grafici contenuti in un'activity. 
Questo perché l'aggiornamento dei componenti visuali è di responsabilità di un thread particolare che 
si chiama main thread (oppure UI Thread) a cui è affidata anche la gestione dei componenti 
principali di un'applicazione, come le note activity o gli intent receiver che invece impareremo a 
utilizzare più avanti nel capitolo. Per risolvere questo problema Android ci fornisce un piccolo 
framework che semplifica l'interazione tra thread diversi di una stessa applicazione e quindi anche 
l'interazione tra lo UI Thread e un thread da noi creato che si indica spesso come worker thread. 

NOTA 

Il lettore ricorderà l'utilizzo di un handler nella realizzazione dell'attività di splash della nostra 
applicazione. 

Alla base di queste API ci sono le seguenti classi: 

• HandlerJ 

• MessageQueue^ 

• Message. 

Sono tutte parte del package android. os che descriveremo nel dettaglio. A ciascun thread, e 
quindi anche al main thread, Android associa ima particolare MessageQueue che, come dice il nome 
stesso, non è altro che una coda di messaggi descritti da istanze della classe Message. Osservando le 
API vediamo come un messaggio non sia altro che una specie di transfert object, un oggetto in 
grado di memorizzare delle informazioni al fine di poterle trasferire in un'unica chiamata. Notiamo 
anche che è una classe che implementa l'interfaccia Parceiabie, che ricordiamo descrivere ima 
funzionalità simile a quella di serializzazione ma in ambito di comunicazione tra processi Da quanto 
detto il lettore potrà intuire che per poter eseguire una particolare azione all'interno di un determinato 
thread basterà inserire nella corrispondente coda un messaggio che ne incapsula le informazioni. Ci 
manca però ancora un meccanismo per creare, inviare e soprattutto consumare i messaggi. È 
abbastanza evidente che l'oggetto responsabile della ricezione dei messaggi dovrà essere un oggetto 
associato al thread di destinazione. Si tratta di una particolare istanza della classe Handler che riceve 
ed elabora i messaggi della MessageQueue associati allo stesso thread nel quale l'handler stesso è stato 
creato. In pratica la ricezione dei messaggi contenenti le informazioni da utilizzare per l'aggiornamento 
dei componenti della UI dovrà essere fatta da un'istanza della classe Handler creata all'interno del 
main thread. Ci manca solo l'ultimo passo relativo alla creazione e invio del messaggio da parte di un 



375 



worker thread. Vedremo che è sufficiente che quest'ultimo abbia il riferimento all'handler per 
chiedergli un'istanza del messaggio relativo alla sua coda. 

Nel Capitolo 2 abbiamo già descritto un esempio di come si possa utilizzare un handler ma non per 
quello che riguarda l'interazione con il thread principale bensì per sfruttarne una delle caratteristiche, 
ovvero quella di inviare un messaggio in differita di un determinato tempo. In questa occasione 
vogliamo invece realizzare un esempio che ci permetta di mettere in evidenza l'utilizzo degli handler e 
allo stesso tempo descrivere un altro tipo di risorsa Drawable, questa volta descritta dalla classe 
ClipDrawable. Abbiamo già visto in precedenza delle implementazioni di Drawable dipendenti dallo 
stato della view a cui lo stesso era applicato. Una ciipDrawabie è invece dipendente da un'altra 
caratteristica della view che si chiama level e che sostanzialmente è un intero che può assumere valori 
tra 0 e 10000. Un ciipDrawabie è una particolare Drawable che esegue il clip (in pratica tronca) di 
un altro Drawable in misura proporzionale al valore del livello della view a cui lo stesso viene 
applicato. Da quanto detto non è difficile capire come si tratti di oggetti utilizzati per la 
rappresentazione di barre di caricamento. Abbiamo realizzato il progetto di nome HandierTest di cui 
riportiamo il codice di interesse. Si tratta di un'applicazione che, alla pressione di un pulsante, avvia 
un worker thread che incrementa un contatore che andrà a modificare il level di una view alla quale 
abbiamo applicato come background un Drawable di tipo ciipDrawabie. Il primo passo è stata la 
creazione di questo tipo di risorsa attraverso la definizione del file ciip_drawabie.xmi nella cartella 
/res/drawable: 

<?xml version="l . 0" encoding="utf-8" ?> 

<clip xmlns : android="http : / /schemas . android . com/ apk/ res/ android" 
android : clipOrientation="horizontal" 
android : gravity=" lef t " 

android : drawable=" @ drawable /ci ip_background"> 
</clìp> 

È una risorsa molto semplice, che viene definita attraverso l'elemento <ciip/> a cui passiamo il 
riferimento al Drawable da rendere progressivo attraverso l'omonimo attributo. Nel nostro caso 
abbiamo deciso di creare una barra colorata attraverso una risorsa del seguente tipo nel file 

clip_background . xml'. 

<?xml version="l . 0" encoding="utf-8 " ?> 
<shape 

android: shape="rectangle" 

xmlns : android="http : //schemas . android. com/ apk/ res/ android" > 

<corners android : radius=" lOdp" /> 

<gradient 

android: startColor="#00FFFF" 

android : endColor="#FFFF00 " /> 
<stroke 

android :color=" #000000" 

android: /> 

</ shape> 

È importante comunque precisare che la clip funziona con un qualunque altro Drawable, per cui 
avremmo potuto utilizzare anche un' immagine (NinePatch oppure no) o una risorsa di tipo 
BìtmapDrawabie. Ilnostro layout è poimolto semplice e contiene una Textview a cui abbiamo 
assegnato come background proprio il nostro ci ipDrawable. Abbiamo poi aggiunto tre pulsanti che ci 
consentiranno di avviare, bloccare e resettare il contatore: 

<TextView 

android : layout_wìdth="match_parent " 
android: layout_ 

android : background= " @drawable/clip_drawable " 

android : ìd=" @+id/progress_view" 

/> 
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Di maggior interesse è la nostra attività descritta dalla classe MainActivity, all'interno della quale 
abbiamo definito il nostro thread contatore: 

public static class CounterThread implements Runnable { 

private WeakRef erence<MainActivity> mActivityRef ; 

private int mCounter; 

private volatile boolean mRunning; 

private Thread mThread; 

public CounterThread (final MainActivity activity) { 

this . mActivityRef = new WeakRef erence<MainActivity> (activity) ; 

} 

public void start () { 
if ( ImRunning) { 

mRunning = true; 

mThread = new Thread (this ) ; 

mThread. start () ; 

} 

} 

public void stop() { 
if (mRunning) { 

mRunning = false; 
mThread = nuli; 

} 

} 

public void reset () { 
if ( ImRunning) { 
mCounter = 0; 
updateValue (mCounter) ; 

} 

} 

SOverride 

public void run ( ) { 
do { 

try { 

Thread. sleep (INTERVAL_TIME) ; 
} catch (InterruptedException ie) { 
} 

updateValue (mCounter) ; 

mCounter += STEP; 
} while (mCounter < MAX_COUNTER_VALUE && mRunning) ; 
updateValue (mCounter) ; 
mRunning = false; 

} 

private void updateValue ( final int newValue) { 

final MainActivity srcActivity = mActivityRef . get ( ) ; 
if (srcActivity != nuli) { 

srcActivity . directUpdateClipDrawable (mCounter) ; 

} 

} 

} 

Innanzitutto vediamo come si tratti di una classe interna statica che implementa l'interfaccia 
Runnable. Come abbiamo imparato nel Capitolo 2, una classe statica non porta con sé il riferimento 
alla particolare istanza della classe esterna in cui è stata definita. Questo ci permette di essere sicuri 
che nel caso in cui il thread non dovesse terminare l'activity non sarebbe vincolata a questo, poiché 
ora il riferimento verso di essa è di tipo weak. L'implementazione dell'interfaccia Runnable ci 
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consenteinvece di avviare e interrompere il thread quante volte vogliamo. Abbiamo infatti 
implementato il metodo start ( ) e stop ( ) in modo da creare una nuova istanza di Thread ogni volta 
che ce ne fosse bisogno. Se avessimo esteso semplicemente la classe Thread, una volta completata 
l'esecuzione del metodo run ( ) non avremmo potuto più riavviarlo. Il metodo run ( ) che abbiamo 
implementato è molto semplice e non fa altro che incrementare il contatore e quindi invocare 
l'aggiornamento della ciipDrawabie attraverso un metodo che abbiamo chiamato updatevaiue ( ) , il 
quale verifica la disponibilità del riferimento all'attività per poi invocarne il metodo 
directupdateciipDrawabie o che, come dice il nome stesso, invoca direttamente l'update del livello 

del nostro ClipDrawable: 

public void directUpdateClipDrawable (final int progressValue) { 
mClipDrawable . setLevel (progressValue) ; 

} 

La classe MainActivìty è molto semplice e non fa altro che inizializzare i vari oggetti tra cui la 
creazione della istanza di counterThread, oltre che gestire gli eventi associati alla pressione dei 
pulsanti di avvio, stop e reset. Se avviamo l'applicazione e premiamo il pulsante Start abbiamo però 
una brutta sorpresa, ovvero un crash e la visualizzazione del seguente log di errore: 

07-08 23:51:35.533 1381-1395/uk . co . massimocarli . android . handlertest E/AndroidRuntime : 
FATAL EXCEPTION: Thread-93 

android . view . ViewRoot Impl$CalledFromWrongThreadException : Only the originai 
thread that createci a view hierarchy can touch its views . 

at android . view .ViewRoot Impl . checkThread (ViewRoot Impl . java : 4 74 6) 

at android . view .ViewRoot Impl . invai ìdateChi Idi nParent (ViewRoot Impl . java : 854 ) 

Come evidenziato il messaggio è molto chiaro: abbiamo invocato un metodo di aggiornamento 
della UI da un thread che non è quello principale, il quale deve necessariamente essere l'unico con 
questa responsabilità. Ecco allora che ci viene in aiuto il nostro handler. Analogamente a quanto fatto 
per la realizzazione della splash abbiamo creato la seguente classe interna statica: 

private static class UpdateHandler extends Handler { 

private WeakRef erence<MainActivity> mActivityRef ; 

public UpdateHandler (final MainActivìty actìvity) { 

this . mActivityRef = new WeakRef erence<MainActivity> (activity) ; 

} 

SOverride 

public void handleMessage (Message msg) { 
if (msg.what == CLIP_UPDATE_WHAT) { 

final MainActivìty srcActivity = mActivityRef . get () ; 
if (srcActivity != nuli) { 

srcActivity . directUpdateClipDrawable (msg . argl) ; 

} 

} 

} 

} 

Da notare come ora l'invocazione del metodo directUpdateClipDrawable o avvenga dall'interno 
del metodo handleMessage o , che è responsabile dell'elaborazione dei messaggi ricevuti. L'aspetto 
fondamentale è però il fatto che ora tale metodo è eseguito all'interno dello UI Thread in quanto 
gestito dall'handler creato al suo interno. La modifica che dobbiamo fare è ora relativa alla modalità 
con cui chiediamo l'aggiornamento, che dovrà corrispondere all'invio di un messaggio. Per questo 
motivo abbiamo implementato questo metodo: 

public void updateClipDrawable (final int progressValue) { 

final Message updateMessage = mUpdateHandler.obtainMessage(CLIP_UPDATE_WHAT) ; 
updateMessage.argl = progressValue; 
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mUpdateHandler . sendMessage (updateMessage) ; 

} 

il quale dovrà essere ora invocato dal nostro thread in occasione di ogni richiesta di aggiornamento: 

private void updateValue (final int newValue) { 

final MainActivity srcActivity = mActivìtyRef . get ( ) ; 
if (srcActivity != nuli) { 

srcActivity . updateClipDrawable (mCounter) ; 



Da notare come la composizione del messaggio sia molto semplice e consista nella creazione di 
un'istanza attraverso il metodo di Factory obtainMessage o e quindi l'impostazione delle informazioni 
di what e argi. Ogni messaggio che possiamo inviare è infatti caratterizzato da un valore numerico 
che si chiama what e che identifica appunto l'azione richiesta. Esistono poi altri attributi di tipo intero 
che si chiamano argi e arg2 a cui è possibile dare valori dipendenti dal contesto. Nel nostro caso 
abbiamo valorizzato solamente argi con il valore per l'aggiornamento. Una volta creato l'oggetto 
Message possiamo inviarlo alla coda e poi all'handler attraverso il metodo s endMessage ( ) . Ora 
finalmente potremo verificare il fijnzionamento corretto del contatore ma soprattutto del 
ClipDrawable, che produrrà una schermata come quella nella Figura 9.1. 
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Figura 9.1 ClipDrawable in esecuzione e utilizzo dell'handler. 

Riassumendo, abbiamo visto come l'utilizzo diunhandler ci permetta di gestire l'interazione tra un 
qualunque thread e quello di gestione della UI. Creando l'istanza di handler all'interno del thread 
principale abbiamo latto in modo che tutti i messaggi inviati venissero elaborati all'interno dello stesso 
thread. A esso corrisponde intatti una MessageQueue nella quale vengono accodati dei messaggi che 
poi vengono elaborati dall'handler all'interno del metodo handleMessage ( ) . 

NOTA 

Nell'implementazione proposta non abbiamo considerato un aspetto che potrebbe risultare 
fondamentale, ovvero che cosa succede nel caso in cui dovessimo ruotare il dispositivo. In quel 
caso il thread non riuscirebbe a sopravvivere e dovremmo implementare un qualche stratagemma 
per garantire il corretto conteggio. In realtà si tratta di uno scenario già visto e che possiamo 
implementare in modo corretto attraverso l'utilizzo di un fragment senza UI. 
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È interessante rilevare come un messaggio si ottenga solamente attraverso opportuni metodi di 
Factory dell'handler che poi li andrà a elaborare. 

Osservando le API relative alla classe Handier rileviamo la presenza di diversi tipi di metodi 
sendMessage ( ) , i quali consentono di specificare anche delle informazioni temporali sull'istante di 
elaborazione del messaggio inviato. Per esempio il metodo 

public boolean sendMessageAtTime (Message rasg, long uptimeMillis ) 

permette di accodare il messaggio passato come parametro in un istante preciso. Notiamo come si 
tratti dell'istante di accodamento e non di consumo da parte dell'eventuale handier. Osserviamo poi 
come l'istante sia rappresentato attraverso un valore di tipo long corrispondente all'orologio interno 
del dispositivo. Tale valore si può ottenere attraverso il metodo statico 

public static long uptimeMillis () 

della classe android . os . SystemClock. Un metodo molto simile al precedente è il seguente: 

public final boolean sendMessageDelayed (Message msg, long delayMillis) 

il quale consente l'inserimento di un messaggio specificando un delay rispetto all'istante attuale 
piuttosto che un valore assoluto. 

Un'altra importante funzionalità della classe Handier è quella di permettere la programmazione di 
attività descritte da particolari implementazioni dell'interfaccia Runnabie già vista, anch'esse eseguite 
all'interno del thread corrispondente. Come nel caso dei messaggi, anche per gli oggetti Runnabie 
esistono diverse possibilità. Attraverso il metodo: 

public final boolean post (Runnable r) 

si può inserire l'elemento Runnable nella coda corrispondente all'handler su cui lo stesso metodo 
viene invocato. Il metodo runo dell'oggetto Runnable verrà eseguito all'interno del thread associato 
all'handler. Analogamente al caso dei messaggi, anche per gli oggetti Runnable c'è l'opportunità di 
accodarli in un determinato istante oppure dopo un particolare delay rispettivamente attraverso i 
metodi 

public final boolean postAtTime (Runnable r, long uptimeMillis) 
public final boolean postDelayed (Runnable r, long delayMillis) 

Sono strumenti che consentono la programmazione nell'esecuzione di particolari operazioni 
all'interno di un particolare thread. 

Looper 

Sebbene sia stato utilizzato per mettere in comunicazione il main thread di gestione della UI con un 
worker thread da noi realizzato, quello degli handier è un meccanismo generale. È infatti possibile fare 
in modo che un qualunque thread consumi, attraverso un proprio handier, un insieme di messaggi 
inviati a partire da un secondo thread che ne possedeva il riferimento. Per dimostrare questa modalità 
di utilizzo supponiamo di voler creare, nell'esempio precedente, un ulteriore thread con funzionalità di 
consumatore dei messaggi inviati dal nostro contatore. Questa volta si tratta però di un thread diverso 
da quello della UI per il quale non esiste ancora alcun handier. Abbiamo già detto che per associare 
un handier a un thread è sufficiente crearne un'istanza all'interno del thread stesso. Oltre a questo si 
deve però creare la MessageQueue associata, quella coda che conterrà tutti i messaggi che poi 
verranno gestiti dall' handier corrispondente. Questo è il compito della classe Looper, che permette 
appunto di implementare una sorta di ciclo il cui compito è quello di prelevare l'eventuale messaggio 
dalla MessageQueue, delegarne la gestione all'handler relativo e quindi elaborare il messaggio 
successivo. La classe interna che ci consente di implementare il thread consumatore è la seguente: 
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private class ConsumerThread extends Thread { 



public Handler consumerHandler ; 

public voìd run ( ) { 
Looper . prepare ( ) ; 

consumerHandler = new Handler ( ) { 
@0verride 

public void handleMessage (Message msg) { 

Log. i (TAG_LOG, "ConsumerThread -> " + msg.obj) ; 

} 

}; 

Looper . loop ( ) ; 

} 

} 

Attraverso l'invocazione del metodo statico Looper .prepare ( ) permette di creare tutto quello che 
serve per poter trasformare il presente thread in una coda in grado di elaborare dei messaggi Di 
seguito inizklizziamo la variabile consumerHandler COn il riferimento al particolare handler che dovrà 
gestire i messaggi all'interno del thread. Infine, il metodo Looper. loop o consente l'avvio del 
MessageQueue associata e l'avvio del thread corrispondente. Per verificarne il funzionamento 
dobbiamo aggiungere il codice che consente di inviare il messaggio al fine di essere consumato e 
precisamente quello evidenziato: 

public void updateClipDrawable ( final int progressValue) { 

final Message updateMessage = mUpdateHandler . obtainMessage (CLIP_UPDATE_WHAT) ; 
updateMessage . argl = progressValue; 
mUpdateHandler . sendMessage (updateMessage) ; 

final Message toConsumerMessage = mConsumerThread . consumerHandler. obtainMessage () ; 
toConsumerMessage . ob j = progressValue; 

mConsumerThread. consumerHandler. sendMessage (toConsumerMessage) ; 

} 

L'unica differenza rispetto al caso precedente riguarda il riferimento all'handler utilizzato. Nel primo 
caso abbiamo utilizzato l'handler relativo al thread di gestione della UI, mentre nel secondo caso 
abbiamo utilizzato l'handler associato al thread del nostro consumatore. 

NOTA 

Il pattern illustrato fa parte del catalogo relativo alla programmazione concorrente e prende il nome 
di pipeline thread. Come descritto sopra, si tratta dell'associazione di un thread a una coda e un 
handler in grado di elaborare i messaggi che contiene. 

Quello descritto è un pattern piuttosto comune nelle applicazioni Andro id per cui l'SDK ha messo 
a disposizione una classe che si chiama HandierThread e appartiene al package android . os. In 
sintesi, è una specializzazione della classe Thread che definisce automaticamente un looper a cui è 
possibile accedere attraverso il metodo getLooper ( ) . Il looper può poi essere usato per la creazione 
dell'handler corrispondente attraverso l'invocazione del seguente costruttore: 

public Handler (Looper looper) 

Per dimostrare l'utilizzo di questa classe abbiamo aggiunto un ulteriore "consumatore", definito 
questa volta come segue all'interno del metodo oncreate o dell' activity: 

final HandlerThread handlerThread = new HandlerThread ( CONSUME R_NAME , CONSUMER_PRIORITY) ; 

handlerThread. start ( ) ; 
mConsumer2Handler = new Handler (handlerThread . getLooper ()) { 

SOverride 

public void handleMessage (Message msg) { 

Log. i (TAG_LOG, "C0NSUMER2 -> " + msg.obj); 

} 

}; 
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In questo caso viene prima creato l'oggetto HandierThread, di cui si possono specificare non solo 
un nome ma anche una priorità, che può assumere uno dei valori corrispondenti alle seguenti costanti: 

HandlerThread . NORM_PRIORITY 
HandlerThread . MIN_PRIORITY 
HandlerThread . MAX_PRIORITY 

Attraverso illooper ottenuto dal metodo getLooper o è possibile creare l'handler che poi 
utilizzeremo per l'invio dei messaggi anche al secondo "consumatore". Prima di questo abbiamo 
avviato il thread attraverso il suo metodo start ( ) . Basterà allora aggiungere, come prima, queste 
istruzioni: 

final Message toConsumer2Message = mConsumer2Handler . obtainMessage ( ) ; 
toConsumer2Message . ob j = progressValue; 
mConsumer2Handler . sendMessage (toConsumer2Message) ; 

Non ci resta che verificare il lùnzionamento dell' applicazione per vedere come effettivamente i 
messaggi vengano gestiti anche dal secondo "consumatore". 

La classe AsyncTask 

Come è facile intuire, lo scenario descritto in precedenza è una situazione molto comune in ambito 
non solo Android ma mobile. La maggior parte delle applicazioni deve infatti eseguire delle operazioni 
in background per poi produrre delle notifiche o comunque visualizzare delle informazioni quando 
queste sono disponibili. A tal proposito la piattaforma Android ha fornito una classe generica 
specializzata allo scopo che si chiama AsyncTask, per descrivere la quale abbiamo realizzato il 
progetto AsyncTaskTest nel quale abbiamo voluto riprodurre lo stesso scenario dell'esempio 
precedente. Alla pressione del pulsante Start vogliamo avviare un task in background che inizia un 
conteggio aggiornando la barra di avanzamento. 

NOTA 

In questo capitolo abbiamo parlato di thread e di task, due concetti sicuramente legati tra loro ma 
distinti. Abbiamo già detto che un thread è una successione di operazioni che agiscono su 
informazioni che possono essere condivise con altri thread. Un thread potrebbe comunque essere 
indefinito; un esempio è il thread relativo a un serversocket che rimane in ascolto delle richieste dei 
client per un tempo indefinito. Un task è invece una successione di operazioni che prima o poi si 
completa e che produce di solito un risultato. L'operazione di download di alcuni dati dalla rete è 
rappresentata da un task e non da un thread. Si tratta, ripetiamo, di concetti comunque correlati, in 
quanto i task vengono solitamente eseguiti all'interno di particolari thread. Senza entrare nello 
specifico, diciamo comunque che Java mette a disposizione due interfaccia diverse: Rumale per i 
thread e caiiabie per i task. 

In base a quanto detto nella nota, esiste una differenza sostanziale rispetto al caso precedente: ora 
abbiamo a che fare con dei task e non con dei thread. Questo significa che, attraverso la nostra 
implementazione di AsyncTask, ci aspettiamo di ottenere un risultato. Anche il significato della funzione 
di stop è diverso, in quanto non rappresenta un' interruzione temporanea ma l'annullamento (o 
cancellazione) del task. Come vedremo, con questa soluzione non sarà possibile (almeno in modo 
semplice) fermare temporaneamente il task per poi farlo proseguire. Sono infatti due scenari diversi 
Per questo motivo abbiamo eliminato il pulsante di reset. Abbiamo poi dato al task il compito di 
calcolare la somma di N numeri dati in ingresso. Osservando il codice della classe MainActivity 
notiamo come sia stata creata la classe interna counterAsyncTask che rappresenta il nostro task e che 
ci accingiamo a descrivere nel dettaglio: 

private class CounterAsyncTask extends AsyncTask<Integer, Integer, Long> { 

private long mSum; 
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@Override 

protected void onPreExecute ( ) { 

super . onPreExecute ( ) ; 

mProgressBar . setVisibility (View . VISIBLE) ; 

} 

@Override 

protected void onPostExecute (Long aLong) { 

super . onPostExecute (aLong) ; 
/ / Nascondiamo la ProgressBar 
mProgressBar . setVisibility (View . GONE) ; 

Toast .makeText (MainAct ivity . this , "TASK COMPLETED ! ! ! Sum:" 
+ mSum, Toast . LENGTH_SHORT) . show () ; 

} 

SOverride 

protected void onCancelled() { 

super . onCancelled ( ) ; 

mProgressBar . setVisibility (View . GONE) ; 

Toast .makeText (MainActivity. this, "TASK CANCELLED ! ! ! Sum:" 
+ mSum, Toast . LENGTH_SHORT) . show () ; 

} 

SOverride 

protected void onProgressUpdate (Integer . . . values) { 

super . onProgressUpdate (values ) ; 
mClipDrawable . setLevel (values [0] ) ; 

} 

@Override 

protected Long doInBackground (Integer . . . numberToCount) { 

final ìnt maxNumber = numberToCount [ 0 ] ; 

final int step = MAX_COUNTER_VALUE / maxNumber; 

mSum = 0; 

int progressValue = 0; 

for (int counter = 0; counter < maxNumber; counter++) { 
if (isCancelled() ) { 

break; 

} 

try { 

Thread. sleep (INTERVAL_TIME) ; 
} catch (InterruptedException ìe) { 

} 

if (isCancelled() ) { 

break; 

} 

mSum += counter; 
progressValue += step; 
Log . d (TAG_L0G, "Sum: " + mSum) ; 
if (isCancelled() ) { 

break; 

} 

publishProgress (progressValue) ; 

} 

/ / Restituiamo la sum 
return mSum; 

} 

} 

Come già accennato, la classe AsyncTask è una classe generica caratterizzata da ben tre diversi tipi 
di dato ciascuno con impreciso significato. Il primo, nel nostro caso un integer, è il tipo dei 
parametri di input dei task, che nello specifico ritroviamo come parametro di input del metodo 
doinBackground ( ) , che contiene appunto il codice relativo al task vero e proprio. La caratteristica 
fondamentale di questo metodo è proprio quella di essere eseguito in un thread diverso da quello 
principale e quindi in background. Nel nostro caso la firma del metodo è la seguente: 
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protected Long doInBackground ( Integer . . . numberToCount ) 

e utilizza un parametro di tipo varargs. Questo significa che potremmo passare in input un numero 
qualunque di parametri di tipo integer. 

Il secondo tipo parametro che abbiamo utilizzato è ancora integer, e rappresenta questa volta il 
tipo del valore che potrà caratterizzare il progredire del task. Si tratta del tipo del valore che 
utilizzeremo per modificare lo stato del nostro ciipDrawabie. 

Il terzo tipo parametro è infine quello del risultato che il nostro task dovrà produrre. Essendo la 
somma di valori teoricamente grandi, abbiamo utilizzato un Long. Anche questo tipo ha delle 
conseguente sulla firma del metodo doInBackground ( ) , determinandone intatti il tipo di ritorno. 

Quali sono i problemi che una classe di questo tipo intende risolvere? Li possiamo elencare come 
segue. 

• Esecuzione di un task in background. 

• Notificare l'avvio e la fine del task all'interno delthread principale. 

• Notificare il progredire del task attraverso l'interazione con lo UI Thread. 

• Gestire la cancellazione del task. 

Il primo obiettivo è fornito dall' AsyncTask attraverso F implementazione del metodo 
doInBackground ( ) . È un metodo che ha come input un varargs corrispondente al tipo indicato in 
occasione della dichiarazione della classe interna e che possiede l'importante caratteristica di essere 
eseguito in un thread separato rispetto a quello principale. La stessa classe AsyncTask ci fornisce poi 
gli strumenti per gestire in qualche modo l'avvio e la conclusione del task attraverso due metodi che 
noi abbiamo implementato come segue: 

@Override 

protected void onPreExecute ( ) { 
super . onPreExecute ( ) ; 

mProgressBar . setvisibilìty (View. VISIBLE) ; 

} 

dOverride 

protected voìd onPostExecute (Long aLong) { 
super . onPostExecute (aLong) ; 
mProgressBar . setvisibility (View . GONE) ; 

Toast .makeText (MainActivìty . this , "TASK COMPLETED ! ! ! Sum:" 
+ mSum, Toast . LENGTH_SHORT) . show () ; 

} 

Il primo, onPreExecute o viene invocato all'avvio del task, mentre il secondo, onPostExecute o , 
viene invocato al completamento dello stesso. Come prima cosa possiamo notare come il secondo 
metodo disponga di un parametro del tipo indicato come risultato. L'aspetto più importante riguarda 
però il fatto che si tratta di due metodi che vengono eseguiti all'interno del thread principale per i quali 
non serve l'implementazione di alcun handler. All'interno di questi metodi possiamo quindi interagire 
senza problemi con tutti gli elementi della UI. Nel nostro caso abbiamo infatti provveduto alla 
visualizzazione o meno di un indicatore rappresentato da un oggetto di tipo ProgressBar. 

Nel nostro esempio vogliamo però far progredire il nostro oggetto di tipo ciipDrawabie, per cui ci 
serve un meccanismo che ci permetta di aggiornarne il valore della proprietà ìevei. A tal scopo la 
classe AsyncTask ci fornisce un'accoppiata di metodi. Il primo è quello che utilizziamo per mettere a 
disposizione il valore che indica il progredire del task. Si tratta del metodo pubiishProgress o che 
abbiamo evidenziato nel codice precedente. Anche qui vediamo come il tipo del parametro di questo 
metodo corrisponda al secondo parametro tipo specificato nell'intestazione della classe interna. È un 
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metodo che viene invocato all'interno del thread in background, il quale dovrà però produrre una 
modifica a livello diUI. Per questo motivo basterà semplicemente eseguire Xoverride del metodo 
onProgressupdate ( ) , che ha il vantaggio di essere eseguito all'interno del thread principale. Nel 
nostro caso l'implementazione è molto semplice 

SOverride 

protected void onProgressUpdate ( Integer . . . values) { 
super . onProgressUpdate (values) ; 
mClipDrawable . setLevel (values [ 0 ] ) ; 

} 

e consiste semplicemente nell'aggiornamento delciipDrawabie. 

Finora non ci sono difficoltà nelT implementare un task durante il quale si ha la visualizzazione di una 
barra di avanzamento o un componente equivalente, in quanto abbiamo visto come utilizzare i metodi 
che ci consentono un'interazione sicura con il thread principale. 

Le cose si complicano invece leggermente se si ha la necessità di fermare il task, cosa che la classe 
AsyncTask rende possibile attraverso il metodo 

public final boolean cancel (boolean maylnterruptlfRunning) 

Il significato di questo metodo è proprio quello di cancellare l'esecuzione del task corrispondente 
sia nel caso in cui lo stesso sia in esecuzione sia qualora lo stesso debba ancora partire. Ricordiamo 
che anche un task, come un thread, non può essere avviato più di una volta per cui in caso di bisogno 
si renderebbe necessaria la creazione di una nuova istanza, come vedremo successivamente. Come 
sappiamo un task è caratterizzato da codice che viene eseguito in background all'interno del suo 
metodo doinBackground ( ) . È bene precisare che l'invocazione del metodo cancei ( ) non interrompe, 
normalmente, tale thread ma imposta a true un flag a cui possiamo accedere attraverso il metodo 
iscanceiied o , come fatto nella nostra implementazione che riportiamo qui per chiarezza: 

@Override 

protected Long doinBackground ( Integer .. . numberToCount ) { 
final int maxNumber = numberToCount [ 0 ] ; 
final int step = MAX_COUNTER_VALUE / maxNumber; 
mSum = 0 ; 

int progressValue = 0; 

for (int counter = 0; counter < maxNumber; counter++) { 
if (isCancelled() ) { break; } 

try { 

Thread. sleep (INTERVAL_TIME) ; 
} catch (InterruptedException ie) { 
} 

if (isCancelled() ) { break; } 

mSum += counter; 
progressValue += step; 
Log. d (TAG_LOG, "Sum: " + mSum) ; 
if (isCancelled() ) { break; } 

publìshProgress (progressValue) ; 

} 

return mSum; 

} 

La responsabilità di interrompere l'esecuzione di un task è dell'implementazione del task stesso, il 
quale, a seconda di quella che è l'operazione da eseguire, dovrà verificarne la cancellazione 
attraverso il metodo iscanceiiedo . In questo caso vediamo come il metodo doinBackground o 
comunque termini la propria esecuzione ritornando un valore che questa volta non viene passato al 
metodo onPostExecute ( ) ma a un altro metodo e precisamente a: 

protected void onCancelled (Long result) 

che noi non abbiamo implementato a favore del suo overload 

protected void onCancelled ( ) 
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per il semplice motivo che si tratta di un metodo disponibile solamente dalla versione relative a un 
API Level 1 1 . In ogni caso, quando un task è cancellato, il metodo onPostExecute ( ) non viene 
invocato. 

Sempre in relazione all'interruzione del task dobbiamo lare una ulteriore considerazione relativa al 
parametro del metodo cancei o che nella maggior parte dei casi passiamo come true. In realtà 
questo valore permette di indicare se debba o meno essere invocato il metodo i nterrupt () sul 
thread che sta eseguendo in quel momento il codice associato al task. Infatti il meccanismo di 
interruzione di un thread è analogo a quanto descritto per i task anche se si basa su metodi diversi 
come interrupto e interrupted ( ) . Ilprimo imposta a true il flag che indica che il thread deve 
essere interrotto e il secondo invece ne verifica lo stato. Tutto può comunque andare per il meglio se 
non fosse per il caso in cui il metodo inter rupt ( ) venisse invocato quando il thread è bloccato, come 
nel caso di invocazione del metodo Thread. sleep ( ) . In quel caso, l'invocazione del metodo 
interrupt o provocherebbe il sollevamento di un'eccezione che bisognerebbe quindi gestire, oltre al 
fatto che lo stato di interruzione verrebbe comunque resettato. Come detto, sono concetti che 
richiedono un approfondimento e per i quali si rimanda a testi specifici 

Tornando al nostro esempio facciamo m'ultima considerazione relativamente al seguente 
frammento di codice: 

public void buttonPressed ( final View pressedButton) { 
switch (pressedButton . getld () ) { 
case R . id . start_button : 

ìf (mCurrentAsyncTask == nuli) { 

mCurrentAsyncTask = new CounterAsyncTask ( ) ; 
mCurrentAsyncTask . execute (100) ; 

} 

break; 
case R . id . stop_button : 

if (mCurrentAsyncTask != nuli && mProgressBar . getVisibility () == 
View.VISIBLE) { 

mCurrentAsyncTask . cancei (true) ; 
mCurrentAsyncTask = nuli; 

} 

break; 

} 

} 

Vediamo infatti come un Asyndask possa essere eseguito una volta sola attraverso il metodo 
execute ( ) a cuipossiamo passare un insieme di parametri del tipo specificato nell'intestazione, che 
nel nostro caso è integer. Notiamo poi l'invocazione del metodo cancei (true) per la cancellazione. 
Ultima nota riguarda poi l'utilizzo dello stato della visibilità della barra di avanzamento al fine della 
determinazione dello stato del task. Lasciamo al lettore la verifica del corretto funzionamento 
dell'applicazione. 

Notification Service 

Una delle funzionalità che hanno da subito caratterizzato la piattaforma Android (e che è stata poi 
ripresa anche dalle altre piattaforme) è la possibilità di visualizzare delle informazioni in modo non 
invasivo attraverso quelle che si chiamano notification (notifiche). Si tratta di messaggi 
(accompagnati da suoni o allarmi visivi) che vengono visualizzate nella parte alta del display che si 
chiama appunto Notification Area (Figura 9.2). 
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Figura 9.2 L'area delle notifiche. 

L'utente può poi eseguire il drag dell'area di notifica visualizzando quello che si chiama 
Notification Drawer (Figura 9.3). E quindi di un modo non invasivo di notifica all'utente, il quale può 
decidere se e quando ottenere maggiori informazioni. 
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Figura 9.3 II Notification Drawer. 



Quella delle notifiche è una tra le funzionalità che hanno avuto più modifiche nel corso delle versioni 
per evi si è avuta la necessità di creare degli strumenti appositi all'interno della Compatibility 
Library; in particolare è stata introdotta la classe Notif icationCompat . Builder, a CUI faremo 
riferimento in questo paragrafo.il suffisso compat è un'abbreviazione di "compatibilità" e consente di 
gestire in modo automatico le diverse versioni eliminando (0 ignorando) le funzionalità non presenti 
nelle versioni precedenti la 4. 1 della piattaforma. 

Essendo un componente gestito dal sistema operativo, gli strumenti a disposizione saranno 
abbastanza rigidi fornendo, come vedremo, solamente alcuni punti di estensione. Uno di questi 
riguarda la possibilità di scegliere tra due diverse modalità di visualizzazione quando espansa. La 
prima si chiama N ormai View, ed è la modalità di default. La seconda è disponibile dalla versione 4. 1 
della piattaforma e si chiama Big View. Si tratta di una modalità che ci permetterà la visualizzazione di 
un numero maggiore di informazioni. E bene precisare comunque da subito che, nelle versioni in cui è 
disponibile, una Big View viene inizialmente sempre presentata come una Normal View a meno che 
non sia la prima dell'elenco delle notifiche, nel qual caso viene visualizzata in modalità espansa. In ogni 
caso si potranno comunque associare dei gesture per far passare la notifica da uno stato a un altro. 

Come detto ogni modalità di visualizzazione consente di definire un insieme di informazioni che 
dipendono anche dalla versione. In ogni caso possiamo dire che la Normal View permette di 
specificare: 
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• un titolo; 

• un'icona grande; 

• un testo; 

• un testo a supporto; 

• un'icona piccola; 

• il tempo a cui la notifica fa riferimento. 

La Big View permette la definizione degli stessi campi ma dispone di uno spazio maggiore per il 
contenuto che può ora assumere diversi stili e precisamente: 

• Big Picture: unica immagine grande (fino a a 256 dp) al centro della notifica; 

• Big Tex: unico testo di discreta lunghezza; 

• Inbox: un elenco di informazioni come nel caso delle e-maiL 

Ciascuno di questi consente poi l'impostazione di un titolo che appare solamente mBig View e, 
sotto questo, un campo di summary. Saranno tutti quei campi impostabili attraverso opportuni 
metodi che non vedremo nel dettaglio e per i quali si rimanda alla documentazione ufficiale. 

Creazione di una notifica 

Per creare una notifica si utilizzano gli strumenti forniti dalla classe Notif icationcompat . Builder, 
la quale implementa appunto il design pattern GoF Builder. Questo significa che, dopo averne creata 
un' istanza, si utilizzeranno una serie di metodi setxx o per impostare le caratteristiche della notifica di 
cui si otterrà un'istanza invocando il metodo buiid ( ) . Una volta ottenuto l'oggetto di tipo 
Notif ication sarà sufficiente invocare imo dei seguenti due metodi per il lancio della stessa: 

public void notify(int id, Notif ication notif ication) 

public void notif y (String tag, int id, Notif ication notif ication) 

come vedremo meglio successivamente. Tra le informazioni che si possono associare a una notifica 
alcune sono obbligatorie e precisamente: 

• un titolo; 

• un testo di dettaglio; 

• un'icona piccola. 

Questi si possono impostare rispettivamente invocando i metodi 

public Notif icatìonCompat . Builder setContentTitle (CharSequence title) 
public Notif ìcationCompat . Builder setContentText (CharSequence text) 
public Notif ÌcationCompat . Builder setSmallIcon (int icon) 

Da notare come il tipo di ritomo sia lo stesso Builder, in modo da poter applicare il chaining. Da 
quanto detto finora la notifica più semplice è quella che comprende un titolo, un testo e un'icona. 
Come esempio dell'utilizzo delle notifiche abbiamo creato una semplice applicazione con una lista di 
opzioni La prima di queste ci consente di generare una notifica che utilizza i metodi precedenti 
all'interno di un metodo di utilità: 

private void showVerySimpleNotif ication ( ) { 

final String contentText = getResources (). getString (R . string . very_simple_text ) ; 
final String contentTìtle = getResources (). getString (R. string . very_simple_title) ; 
Notif ication notif ication = new Notif ÌcationCompat . Builder (this ) 

. set Smalli con (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setContentTitle (contentTìtle) . build ( ) ; 
mNotif ìcationManager .notif y (VERY_SIMPLE_NOTIFICATION, notif ication) ; 

} 
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Vediamo come la notifica sia stata ottenuta utilizzando il NotificationCompat .Builder attraverso il 
quale abbiamo impostato le informazioni necessarie e quindi invocato il metodo buiid ( ) . Attraverso il 
NotificationManager, di cui abbiamo ottenuto un'istanza attraverso ristruzione 

mNotif icationManager = (NotificationManager) 

getSystemService (Context .NOTIFICATION_SERVICE) ; 

abbiamo generato la notifica come mostrato nelle Figure 9.3 e 9.4. Un aspetto strano riguarda il 
tatto che i metodi che permettono di assegnare il titolo e il testo necessitino della String e non si 
accontentino dell'id della risorsa corrispondente. Altro aspetto importante riguarda il valore dell' id 
che passiamo come primo parametro al metodo notif y ( ) , che ci consente di gestire il 
comportamento della notifica nel caso ve ne fosse una lanciata in precedenza con lo stesso 
identificatore. 




Figura 9.4 L'icona relativa alla notifica è visualizzata nella Notification Area. 




Figura 9.5 Le informazioni relative alla notifica vengono visualizzare nel Notification Drawer. 

Una prima osservazione relativa alla notifica generata dal codice precedente riguarda il fatto che la 
stessa è insensibile alla selezione. Facendo clic su di essa non si ha infatti alcun effetto. Le API a 
nostra disposizione permettono però l'aggiunta di azioni che solitamente, ma non necessariamente, 
corrispondono al lancio di un intent per la visualizzazione di un'activity. Sebbene non si tratti di 
qualcosa di obbligatorio è sempre bene assegnare un'azione alla selezione della notifica. 

A ciascuna di queste azioni possiamo associare quelli che si chiamano Pendingintent e che 
rappresentano un concetto di fondamentale importanza nell'architettura diAndroid. Come sappiamo 
un intent è un oggetto che incapsula le informazioni relative a una particolare azione che la nostra 
applicazione intende eseguire. Negli esempi visti fino a questo momento, ogni applicazione crea e 
lancia oggetti di tipo intent che essa stessa crea. In altri contesti, come quello delle notifiche, il 
processo responsabile dell'invio dell'intent non è lo stesso che lo ha creato. Le notifiche sono infatti 
gestite dal sistema Andro id, mentre gli intent che vorremmo lanciare sono gestiti dall'applicazione. Per 
risolvere questo problema sono stati creati i p endinglntent, 1 quali incapsulano non solo un intent che 
è possibile lanciare in un momento successivo ma anche, e soprattutto, i diritti per poterlo fare. In 
pratica se diamo a un'altra applicazione un Pendingintent per il lancio di un intent, le diamo tutti i 
diritti dell'applicazione. Questo succede addiritttura anche nel caso in cui il processo dell'applicazione 
che ha creato l' intent sia stato eliminato. È interessante sottolineare come due istanze diverse di intent 
relative allo stesso evento portino comunque alla definizione dello stesso Pendingintent anche nel 
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caso in cui questi si differenzino per gli extra, che non sono quindi utilizzati nel confronto. Questo 
significa che gli extra non sono informazioni sufficienti nel differenziare due Pendingintent che devono 
generare no tifiche diverse ma dello stesso tipo. 

È importante inoltre sottolineare come non si possa creare un Pendingintent attraverso il relativo 
costruttore ma solamente attraverso uno dei seguenti metodi di Factory che definisce anche il tipo del 
componente di destinazione. 

Per creare un Pendingintent per il lancio diun'activity possiamo utilizzare uno dei seguenti metodi: 

public static Pendinglntent getActivity (Context context, int requestCode, 
Intent intent, int flags) 

public static Pendinglntent getActivity (Context context, int requestCode, 
Intent intent, int flags, Bundle options) 

Il primo parametro rappresenta il riferimento alla particolare implementazione di Context che poi 
dovrà lanciare F intent che viene invece passato come terzo parametro. Il secondo parametro al 
momento non è utilizzato, mentre assumono molta importanza i flag che possiamo passare come 
quarto parametro, e che possono assumere uno di questi valori: 

Pendinglntent . FLAG_ONE_SHOT 
Pendinglntent . FLAG_NO_CREATE 
Pendinglntent . FLAG_CANCEL_CURRENT 
Pendinglntent . FLAG_UPDATE_CURRENT 

La costante flag_one_shot sta a indicare che il Pendinglntent può essere utilizzato solamente una 
volta. Il valore flag_no_create permette invece di ritornare un valore nuli nel caso in cui l' intent non 
fosse già attivo in una notifica. Può quindi essere utilizzato per verificare se un Pendinglntent esiste 
già oppure no. Il flag flag_cancel_current è molto importante anche alla luce di quanto detto prima 
in relazione a questo tipo di oggetto. Nel caso in cui il Pendinglntent che si intende creare dovesse 
già esistere, i metodi precedenti ritorneranno un nuovo Pendinglntent ma solamente dopo aver 
eliminato il precedente. È un metodo utile nel caso in cui il nuovo Pendinglntent dovesse 
differenziarsi solamente per i valori di alcuni extra. Infine, il flag flag_update_current consente di 
mantenere comunque il Pendinglntent se esistente aggiornando solamente i valori degli extra 
corrispondenti Si tratta di un' alternativa al caso precedente, che non prevede la creazione di un 
nuovo Pendinglntent. Oltre a questi flag è interessante notare come sia possibile anche decidere 
quale parte dell' intent modificare attraverso l'utilizzo di una serie di flag del tipo 
intent. fill_in_action, intent . fill_in_categories e così via, per i quali rimandiamo alla 
documentazione ufficiale. 

I due overload descritti si differenziano poi per la presenza dell'ultimo parametro di tipo Bundie, 
che permette di passare informazioni aggiuntive all'activity di destinazione. 

Oltre a questi due metodi esiste anche la versione che consente di lanciare più attività attraverso 
uno di questi metodi: 

public static Pendinglntent getActivìties (Context context, int requestCode, 

Intenti] ìntents, int flags) 
public static Pendinglntent getActivities (Context context, int requestCode, 

Intenti] intents, int flags, Bundle options) 

In questo caso si creerà un Pendinglntent per il lancio delle attività corrispondenti agli intent 
passati come terzo parametro. 

Tornando alla gestione delle no tifiche, l'azione più semplice che possiamo associare è quella 
relativa all'evento di cancellazione della stessa attraverso il gesto o il pulsante corrispondente. Per 
farlo abbiamo bisogno di settare la notifica come "cancellabile" con il metodo 
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public Notif icationCompat . Builder setAutoCancel (boolean autoCancel) 

e associare ilpendingintent relativo attraverso il metodo 

public Notif icationCompat . Builder setDeletelntent (Pendinglntent intent) 

A tal proposito abbiamo creato il seguente metodo di test: 

private void showSimpleCancellableNotif ication ( ) { 

final Intent destlntent = new Intent (this, DestinationActivity . class ) ; 
final Pendinglntent deletelntent = Pendinglntent . getActìvity (this, 

0, destlntent, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final String contentText = getResources ( ) 

. getStrìng (R . string . very_simple_cancellable_text ) ; 
final String contentTitle = getResources ( ) 

. get String (R . string . very_simple_cancellable_title) ; 
Notifìcation notif ication = new Notif icationCompat . Builder (this ) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 

. setDeletelntent (deletelntent) 

. set ContentTitle (contentTitle) . build ( ) ; 
mNotif icationManager . notìfy (SIMPLE_CANCELLABLE_NOTIFICATION, notif ication) ; 

} 

Attraverso i metodi precedenti si può quindi associare un intent alla cancellazione dell' intent. Una 
volta generata, la notifica appare come la precedente. Non appena però la cancelliamo noteremo 
come l'activity impostata venga effettivamente lanciata. 
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Figura 9.6 Attività di destinazione visualizzata a seguito della cancellazione della notifica. 

Se invece selezioniamo la notifica noteremo come ancora non succeda nulla. Per tarlo è possibile 
utilizzare questo metodo 

public Notif icationCompat . Builder setContentlntent (Pendinglntent intent) 

che abbiamo testato all'interno del seguente metodo: 

private void showNormalNotif ication ( ) { 

final Intent destlntent = new Intent (this, DestinationActivity . class ) ; 
final Pendinglntent deletelntent = Pendinglntent . getActivity (this , 0, 

destlntent, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent selectedlntent = new Intent (this, DestinationActivity . class) ; 
selectedlntent .putExtra (DestinationActivity . OUTPUT_EXTRA, 

"As Content Intent") ; 
final Pendinglntent selectedPendinglntent = Pendinglntent . getActivity (this, 

0, selectedlntent, Pendinglntent .FLAG_CANCEL_CURRENT) ; 
final String contentText = getResources ( ) 

. getString (R . string . very_simple_cancellable_text ) ; 
final String contentTitle = getResources ( ) 

. getString (R. string . very_simple_cancellable_title) ; 
Notif ication notif ication = new Notif icationCompat . Builder (this) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 

. setDeletelntent (deletelntent) 

. setContentlntent (selectedPendinglntent) 

. set ContentTitle (contentTitle) . build ( ) ; 
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mNotif icationManager . notif y (NORMAL_NOTIFICATION, notif ication) ; 

} 

dove abbiamo messo in evidenza la parte relativa alla selezione della notifica per la quale lanciamo 
un intent contenente un extra che ci permetterà di individuarlo nell'attività di destinazione, come 
possiamo vedere nella Figura 9.7. 
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Figura 9.7 Attività di destinazione per la selezione della notifica. 

Il lettore potrà però notare come nel terzo esempio non funzioni più la gestione della cancellazione. 
Si tratta di un classico errore relativo a quanto abbiamo detto sul confronto tra due Pendinglntent. 
Nel nostro caso i due si differenziano solamente per il valore di un extra, che non è però sufficiente. 

NOTA 

Negli esempi che seguono utilizzeremo spesso i puntini (...) come modo per ridurre la dimensione 
delle action. Nel codice dell'applicazione il valore di queste stringhe è corretto. 

Dobbiamo quindi creare un modo alternativo per definire due intent che si differenzino per azione, 
category o data, mentre il precedente viene lanciato attraverso un intent esplicito; definiamo per 
Fattività di destinazione anche un intent filter usando la seguente definizione: 

<activìty android: name=" . DestinationActivity " android : label="@string/app_name"> 
<intent-f ilter> 

<action android: name="co . uk . massimocarli . . . . action .ALIAS " /> 
<category android: name=" android. intent . category . DEFAULT" / > 
</intent-filter> 
</ activity> 

Ci siamo inventati un'action che ci consentirà di lanciare la stessa attività di destinazione sia per la 
cancellazione della notifica sia per la selezione della stessa. Il metodo precedente diventa quindi il 
seguente: 

private void showNormalNotif ication ( ) { 

final Intent destlntent = new Intent (this, DestinationActivity . class ) ; 
final Pendinglntent deletelntent = Pendinglntent . getActivity (this , 0, 

destlntent, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent selectedlntent = 

new Intent ( "co . uk .massimocarli . . . . action .ALIAS") ; 
selectedlntent .putExtra (DestinationActivity . OUTPUT_EXTRA, 

"As Contentlntent"); 

final Pendinglntent selectedPendinglntent = 

Pendinglntent . getActivity (this , 0, selectedlntent, 

Pendinglntent .FLAG_CANCEL_CURRENT) ; 
final String contentText = getResources ( ) 

. getString (R . string . very_simple_cancellable_text ) ; 
final String contentTitle = getResources ( ) 

. getString (R . string . very_simple_cancellable_title) ; 
Notif ication notif ication = new Notif icationCompat . Builder (this ) 

. setSmallIcon (R. drawable . ìc_launcher) . setContentText (contentText) 

. setAutoCancel (true) 

. setDeletelntent (deletelntent) 

. setContentlntent (selectedPendinglntent) 

. setContentTìtle (contentTitle) . build ( ) ; 
mNotif icationManager . notif y (NORMAL_NOTIFICATION, notif ication) ; 
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la cui modifica, evidenziata nel codice ha risolto il nostro problema. 

Dalla versione 4.1 della piattaforma Andro id, quando una notifica è nello stato espanso, è possibile 
aggiungere dei pulsanti a cui associare determinate azioni personalizzate. Nel caso della mail vengono 
per esempio visualizzate le opzioni di archiviazione o di reply, come nella Figura 9.8. 




Figura 9.8 Azioni personalizzate: associare a una notifica in versione espansa. 

Per poter implementare questa funzionalità è sufficiente utilizzare le seguenti operazioni del nostro 

Oggetto Builder: 

public Notif icationCompat . Builder addAction (int icon, CharSequence title, 

Pendinglntent intent) 

Vediamo come permetta di associare a ciascuna azione un'icona, un titolo e il relativo 
Pendinglntent. Se volessimo associare tre diversi p endinglntent ad altrettante azioni potremmo 
utilizzare il seguente codice, nel quale abbiamo evidenziato le parti di interesse. È comunque di 
fondamentale importanza ricordarsi che queste azioni sono visualizzare nel modo descritto solamente 
a partire dalla versione 4.1 della piattaforma. Per quelle precedenti bisognerà mettere l'utente nelle 
condizioni tali da poterne usufruire. Per questo motivo si tratterà di funzioni che saranno comunque 
accessibili dall'attività di destinazione associata alla semplice selezione della notifica: 

private void showCustomActionsNotif ication ( ) { 

final Intent deletelntent = new Intent (this, DestinationActivity . class) ; 
final Pendinglntent deletePendinglntent = Pendinglntent . getActivity (this , 0, 

deletelntent, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionlntentl = new Intent (this, DestinationActivity . class ) ; 
actionlntentl .putExtra (DestinationActivity . OUTPUT_EXTRA, "Custom Action 1") ; 
final Pendinglntent actionPendinglntentl = Pendinglntent .getActivity (this, 

0, actionlntentl, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionIntent2 = 

new Intent ( "co . uk .massimocarli .... action .ALIAS " ) ; 
actionIntent2 .putExtra (DestinationActivity . OUTPUT_EXTRA, "Custom Action 2"); 
final Pendinglntent actionPendingIntent2 = Pendinglntent . getActivity (this, 

0, actionIntent2, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionIntent3 = 

new Intent ( "co . uk .massimocarli . . . . action .ALIAS2" ) ; 
actionIntent3. putExtra (DestinationActivity. OUTPUT_EXTRA, "Custom Action 3"); 
final Pendinglntent actionPendingIntent3 = Pendinglntent .getActivity (this, 

0, actionIntent3, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Strìng contentText = getResources ( ) 

. getString (R. string . custom_action_cancellable_text ) ; 
final String contentTitle = getResources ( ) 

. getString (R . strìng . custom_action_cancellable_title) ; 
Notif ication notif ication = new Notif icationCompat . Builder (this) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 
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. setDeletelntent (deletePendinglntent ) 

. setContentlntent (actionPendinglntentl ) 

. addAction (android . R . drawable . ic_input_add, "Actionl " , 

actionPendinglntentl) 
. addAction (android . R . drawable . ic_input_delete , "Action2 " , 

act ionPendingIntent2 ) 
. addAction (android . R . drawable . ic_input_get , "Action3 " , 

actionPendingIntent3) 
. setContentTitle (contentTitle) .build () ; 
mNotif icationManager .notify (CUSTOM_ACTIONS_NOTIFICATION, notif ication) ; 

} 

Anche in questo caso notiamo come sia stato necessario associare delle azioni diverse ai vari 
Pendinglntent in modo che gli stessi vengano considerati come diversi. A questo punto, prendendo 
delle icone tra quelle disponibili nella piattaforma, abbiamo generato la notifica nella Figura 9.9. 
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Figura 9.9 Notifica con le azioni personalizzate. 

Nonostante fossero state definite delle azioni personalizzate, abbiamo dovuto comunque 
specificare 1 Pendinglntent relativi alla cancellazione e selezione. Lasciamo al lettore la verifica del 
corretto funzionamento dell'esempio. 

In precedenza abbiamo detto che dalla versione 4.1 sono disponibili altre tipologie di notifica, che 
sono ora caratterizzate da quello che si chiama stile, il quale può essere impostato attraverso il 
seguente metodo del nostro Builder : 

public Notif icationCompat . Builder setStyle (Notif icationCompat . Style style) 

dove il parametro è un riferimento a un oggetto di tipo Notif icationCompat . style, che può essere 
descritto da una di queste specializzazioni: 

Notif icationCompat . BigPictureStyle 
Notif icationCompat . BigTextStyle 
Notif icationCompat . InboxStyle 

per, le quali realizziamo sei semplici esempi La prima specializzazione, come dice il nome stesso, 
consente di riempire lo spazio a disposizione della notifica con un'unica immagine che è possibile 
specificare come nell'esempio: 



private void showBìgPictureNotif ication ( ) { 

final Intent deletelntent = new Intent(this, DestinationActivity . class) ; 
final Pendinglntent deletePendinglntent = Pendinglntent . getActivity (this, 

deletelntent, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionlntentl = new Intent (this, DestinationActivity . class ) ; 
actionlntentl .putExtra (DestinationActivity . OUTPUT_EXTRA, "Custom Action 1" 
final Pendinglntent actionPendinglntentl = Pendinglntent .getActivity (this, 

0, actionlntentl, Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Strìng contentText = getResources ( ) 

. getString (R. string . big__picture_text ) ; 
final String contentTitle = getResources ( ) 

. getString (R . string .big__picture_tit le) ; 



0, 



) ; 
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final Bitmap largelmage = BitmapFactory . decodeResource (getResources ( ) , 

R. drawable . android_bigimage) ; 
Notification notification = new Notif icationCompat . Builder (this ) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 

. setDeletelntent (deletePendinglntent ) 

. setContentlntent (actionPendinglntentl ) 

. setStyle (new Notif icationCompat . BigPictureStyle ( ) 

.bigPicture (largelmage) ) 

. setContentTitle (contentTitle) .build() ; 
mNotif icationManager .notif y (BIG_PICTURE_NOTIFICATION, notification) ; 

} 

Il risultato è mostrato nella Figura 9.10. 




Figura 9.10 Esempio di una notifica di stile BigPicture. 



Il successivo tema (Notif icationCompat. BigTextstyie) ci permette invece di riempire uno spazio 
maggiore con del testo, come abbiamo latto in questo codice di esempio: 

private void showLongTextNotif ication ( ) { 

final Intent deletelntent = new Intent (this, DestinationActivity . class) ; 
final Pendinglntent deletePendinglntent = 

Pendinglntent . getActivity (this, 0, deletelntent, 

Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionlntentl = new Intent (this, DestinationActivity . class) ; 
actionlntentl .putExtra (DestinationActivity . OUTPUT_EXTRA, "Custom Action 1") ; 
final Pendinglntent actionPendinglntentl = 

Pendinglntent . getActivity (this, 0, actionlntentl, 

Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final String contentText = getResources (). getString (R. string . big_text_text ) ; 
final String contentTitle = getResources ( ) 

. getString (R . string .big_text_tit le) ; 
final String longText = getResources (). getString (R . string . long_text ) ; 
final String longSummaryText = getResources ( ) 

. getString (R. string . summary_text ) ; 
Notification notification = new Notif icationCompat . Builder (this) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 

. setDeletelntent (deletePendinglntent) 
. setContentlntent (actionPendinglntentl ) 

. setStyle (new Notif icationCompat . BigTextStyle () .bigText (longText) 
. setSummaryText (longSummaryText) ) 
. setContentTitle (contentTitle) .build() ; 
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mNotif icationManager . notif y (BIG_TEXT_NOTIFICATION, notif ication) ; 



che produce il risultato nella Figura 9.11. 
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Big Text Notification oo*: 

Lorem Ipsum is simply dummy text of the 
printing and typesetting industry. Lorem Ipsum 
has been the industry's standard dummy text 
ever since the 1 500s, when an unknown 
printer took a galley of type and scrambled it to 
make a type specimen book. It has survived 
not only fìve centuries, but also the leap into 
electronic typesetting, remaining essentially... 



I didn't study latin at school! 



Figura 9.11 Esempio di notifica con stile BigText. 

Il terzo stile è invece quello tipico di un elenco di e-mail e per questo motivo è stato chiamato 
Notif icationcompat . inboxstyie. Esso consente di organizzare il contenuto della notifica in righe: 

private void showInboxNotif ication ( ) { 

final Intent deletelntent = new Intent (this, DestinationAotivity . class) ; 
final Pendinglntent deletePendinglntent = 

Pendinglntent . getActivity (this, 0, deletelntent, 

Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final Intent actionlntentl = new Intent (this, DestinationAotivity . class) ; 
actionlntentl .putExtra (DestinationAotivity . OUTPUT_EXTRA, "Custom Action 1") ; 
final Pendinglntent actionPendinglntentl = 

Pendinglntent . getActivity (this, 0, actionlntentl, 

Pendinglntent . FLAG_CANCEL_CURRENT) ; 
final String contentText = 

get Resources ( ) . get String (R. string . inbox_style_text ) ; 
final String contentTitle = getResources ( ) 

. get String (R . string . inbox_style_title) ; 
Notification notification = new Notif icationCompat . Builder (this ) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setAutoCancel (true) 

. set De lete Intent (deletePendinglntent ) 
. setContentlntent (actionPendinglntentl) 

. setStyle (new Notif icationCompat . InboxStyle ( ) . addLine ( "Line 1") 
.addLine ("Line 2 "). addLine ( "Line 3 "). addLine ( "Line 4") 
. setSummaryText ( " 4 Messages")) 
. set ContentTitle (contentTitle) . build ( ) ; 
mNotif icationManager .notif y ( INBOX_NOTIF ICATION, notification) ; 



Il risultato è mostrato nella Figura 9.12. 
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Figura 9.12 Una notifica con lo stile Inbox. 



Fino a questo momento abbiamo parlato di come ima notifica possa essere creata e quindi lanciata 
attraverso il metodo notify o della classe Notif icationManager. 

NOTA 

Il nome notify o è un po' infelice: è troppo simile a quello di cui ogni oggetto dispone e che assume 
importanza nel processo di rilascio di un lock in un contesto concorrente 

In tale occasione abbiamo visto come, oltre al riferimento all'oggetto di tipo Notif ication, vi sia 
anche un identificatore, il quale ha importanza nelle operazioni di aggiornamento e rimozione della 
notifica. Il meccanismo alla base è molto semplice; per aggiornare una notifica è sufficiente invocare 
nuovamente il metodo notify ( ) specificando lo stesso valore per il parametro id. Come 
dimostrazione di questo abbiamo creato il seguente esempio, che non fa altro che incrementare un 
contatore che viene visualizzato all'interno della notifica: 

private void sendRepeatedNotif ication ( ) { 

final String counterText = "Counter:" + (mCounter++) ; 
Notification notif ication = new Notif icationCompat . Builder (this) 

. setSmallIcon (R . drawable . ic_launcher ) . setContent Text (counterText ) 
.buildO ; 

mNotif icationManager . notify (REPEATED_NOTIF ICATION, notification) ; 

} 

Il lettore potrà verificare come la notifica venga in effetti aggiornata mostrando un messaggio con il 
valore del contatore in quel momento. Questo a dimostrazione del fatto che le informazioni relative a 
una particolare notifica vengono aggiornate se la notifica è già esistente, mentre ne viene creata una 
nuova nel caso in cui la stessa non fosse presente. Il risultato sarà simile a quello mostrato nella Figura 
9.13. 




Figura 9.13 La notifica viene aggiornata a ogni selezione. 



Per concludere la descrizione del ciclo di vita di una notifica possiamo dire che la stessa può essere 
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rimossa, oltre ai casi già visti, anche invocando imo di questi metodi: 

public void cancel (int id) 

public void cancel (String tag, int id) 

public void cancelAll() 

Il primo permette la cancellazione di una notifica associata all'id passato come parametro. Il 
secondo utilizza anche il tag nel caso in cui lo stesso fosse stato utilizzato in fase di notifica. Il terzo 
consente la cancellazione di tutte le notifiche aperte in quel particolare momento. 

Notifiche e navigazione tra activity 

Come sappiamo, Google ha rilasciato delle linee guida relative alla creazione delle applicazioni 
Android. Si tratta non solo di regole che descrivono come debbano essere realizzati i diversi 
componenti grafici, ma soprattutto regole relative alle varie modalità di navigazione. La nostra 
applicazione di esempio non è, al momento, conforme a queste regole. Per dimostrare questa 
affermazione lanciamo l'applicazione e selezioniamo la terza opzione, ovvero del lancio di una Simple 
Closeable Notification. A questo punto la notifica compare nella Notification Area. Chiudiamo 
allora l'applicazione selezionando il pulsante Back. Apriamo 'A Notification Drawer e selezioniamo la 
notifica, la quale provoca la visualizzazione dell' activity di destinazione. Ora, se premiamo il pulsante 
Back usciremo dall'applicazione senza passare attraverso il nostro menu descritto dalla classe 
MainActivity. Le regole generali vorrebbero che se raggiungiamo un'attività, che possiamo definire 
di secondo livello, direttamente da una notifica, premendo il pulsante Back si dovrebbe ritornare 
all'attività di primo livello, come se si fosse arrivati lì attraverso la normale esecuzione 
dell'applicazione. 

Per sistemare il tutto dobbiamo eseguire alcune semplici operazioni. Innanzitutto dovremo 
informare l'activity lanciata attraverso la notifica dell'esistenza di un livello superiore che in questo 
caso è stato saltato, ma a cui si dovrà comunque ritornare attraverso un evento di back. Per farlo si 
utilizzano due modi diversi che ci permetteranno di gestire sia le ultime versioni della piattaforma sia 
quelle precedenti la versione 4.0.3. Il primo prevede l'utilizzo di un <meta-data/>, mentre il secondo 
prevede l'utilizzo dell'attributo android:parentActivityName. La definizione dell'attività di 
destinazione diventerà la seguente: 

<actìvity android: name=" . DestinationActivity " 
android : labe 1="@ string/ app_name " 
android : parentActivityName=" . MainActivity" > 

<intent-f ilter> 

<action android : name=" co . uk .massimocarli . . . . action .ALIAS" /> 
<action android : name=" co . uk .massimocarli . . . . action . ALIAS2 " /> 
<category android : name=" android . intent . category . DEFAULT" /> 

</ intent-f ilter> 

<meta-data android : name= " android . support . PARENT_ACTIVITY " 
android: value=" . MainActivity" /> 

</activity> 

In ogni caso rinformazione che vogliamo dare è quella di un riferimento all'attività che dovrebbe 
fungere da padre o sorgente di quella di destinazione dalla notifica. Ora vogliamo costruire il back 
stack corrispondente aiutandoci con una classe che si chiama TaskstackBuiider. In particolare 
dobbiamo eseguire le seguenti operazioni: 

private void showBackStackNormalNotif ication ( ) { 

final Intent selectedlntent = new Intent (this, DestinationActivity . class) ; 
TaskstackBuiider stackBuilder = TaskstackBuiider . create (this ) ; 
stackBuilder . addParentStack (DestinationActivity . class) ; 
stackBuilder . addNext Intent (selectedlntent ) ; 

stackBuilder . edìtlntentAt ( 1 ) .putExtra (DestinationActivity . OUTPUT_EXTRA, 
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"Back Staok Action"); 
final Pendinglntent selectedPendinglntent = stackBuilder . getPendinglntent ( 0, 

Pendinglntent . FLAG_UPDATE_CURRENT) ; 
final String contentText = getResources ( ) 

. getStrìng (R . string . very_simple_cancellable_text ) ; 
final String contentTitle = getResources ( ) 

. get String (R . string . very_simple_cancellable_title) ; 
Notification notification = new Notif icationCompat . Builder (this) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setContentlntent (selectedPendinglntent) 

. setContentTitle (contentTitle) .build () ; 
mNotif icationManager .notify ( BACK_S T ACK_NOT I F I CAT I ON , notification) ; 

} 

Dopo aver creato l'intent associato all'activity di destinazione, otteniamo un' istanza dell'oggetto 
TaskstackBuiider attraverso il suo metodo statico di Factory TaskStackBuilder . create ( ) . A questo 
punto utilizziamo il metodo addParentstack o per aggiungere alback stack il riferimento a tutte le 
attività padre di quella passata come parametro. Attraverso questo metodo vengono quindi prese 
tutte le attività specificare attraverso il <meta-data/> o l'attributo parentActivityName e aggiunte al 
back stack. Fatto questo dobbiamo registrare il riferimento all'intent di destinazione invocando il 
metodo addNextintent o . Nelnostro caso l'intent dispone anche di un extra gestibile attraverso il 
metodo editintentAt o . L'oggetto TaskstackBuiider ha ora tutte le informazioni necessarie alla 
costruzione del p endinglntent che verrà lanciato in corrispondenza della selezione della notifica. Non 
ci resta che provarlo ripetendo gli stessi passi del caso precedente. Ora, la selezione della notifica ci 
porta alla visualizzazione di quanto ottenuto nella Figura 9.14. 




Figura 9.14 Activity ottenuta a seguito della selezione della notifica. 

Come possiamo vedere nella figura, il fatto che non si tratti dell'unica activity attiva per 
l'applicazione è esplicitato dalla presenza della icona Home in alto a sinistra. Selezionando il pulsante 
Back torneremo quindi alla nostra Home come in effettivamente ci aspettavamo grazie all'utilizzo della 

classe TaskstackBuiider. 

Quello descritto è comunque il caso in cui l'attività di destinazione è parte di un'applicazione. Nel 
caso in cui si avesse la necessità di utilizzare un' activity come prolungamento delle informazioni nella 
notifica, lo scenario sarebbe diverso e non prevederebbe l'utilizzo di strumenti di gestione delback 
stack. In questo caso la selezione della notifica porta alla visualizzazione di un' activity da cui, 
attraverso il pulsante Back, si ha la visualizzazione della Home del dispositivo. Per questo tipo di 
comportamento rimandiamo alla documentazione ufficiale. 



Notifiche dinamiche 

Come sappiamo spesso i dispositivi mobili eseguono delle operazioni di sincronizzazione che 
avvengono in background e provvedono alla modifica della base dati locale secondo particolari 
informazioni remote. In questi casi sono a disposizione alcuni strumenti che permettono la 
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visualizzazione di un indicatore sia nel caso in cui si conosca una stima del tempo di completamento 
sia in caso contrario. Nei due casi si utilizza infatti un componente diverso, ovvero una barra di 
avanzamento oppure un activity indicator, rispettivamente, mentre nelle versioni precedenti la 4.0 si 
rende necessaria la creazione di un layout personalizzato per la notifica. Ora è disponibile questo 
metodo: 

public Notif icationCompat . Builder setProgress (int max, int progress, boolean 
indeterminate) 

che ci consente di specificare appunto il valore massimo rappresentato dalla barra, il valore 
corrente e il tipo che può essere hdeterrninato (tempo non definito) oppure non hdeterrninato (tempo 
definito). Si tratta di un metodo che viene invocato molto e che va ad aggiornare le informazioni 
nell'area delle notifiche. La rimozione della barra è quindi possibile attraverso l'istruzione 
setProgress (0, 0, false) . La responsabilità della visualizzazione del messaggio di completamento è 
quindi dell'applicazione, come possiamo vedere nell'esempio: 

private void showDeterminateNotif ication ( ) { 
final Strìng contentText = getResources ( ) 

. getString (R. string . determinate_text ) ; 
final String oontentTitle = getResources ( ) 

. getString (R . string . determinate_title) ; 
final Notif icationCompat . Builder builder = 

new Notif icationCompat .Builder (this) 

. setSmallIcon (R. drawable . ic_launcher) 

. setContentText (contentText) 

. setContentTitle (contentTitle) ; 

final int maxValue = 100; 

new ThreadO { 
SOverride 

public void run ( ) { 

int progressValue = 0; 

for (int value = 0; value < maxValue ; value +=5) { 
builder . setProgress (maxValue, value, false); 
mNotif icationManager .notify ( DE TERM I NATE_NOT I F I CAT I ON , 
builder .build ( ) ) ; 

try { 

Thread. sleep (200) ; 
} catch ( InterruptedException ie) { } 

} 

builder . setProgress ( 0 , 0, false); 
builder . setContentText ("Completed! ") ; 

mNotif icationManager . notify ( DETERMINATE_NOT I F I CAT I ON , 
builder . build ( ) ) ; 

} 

} . start ( ) ; 

} 

Il risultato è quello mostrato nella Figura 9.15, fino ad arrivare al risultato illustrato nella Figura 
9.16. 









□ 


This is a Notification for a progress of determinate type 




avast! Mobile Security 09*0 



Figura 9.15 La notifica relativa al determinate task. 
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Determinate progress notification 09*2 

Completed! 



avast! Mobile Seouritv 



Figura 9.16 II task è stato completato. 

Come esercizio lasciamo al lettore la creazione di una notifica relativa a un task di tipo 
indeterminate. In realtà si tratta di sostituire semplicemente l'istruzione: 

builder . setProgress (maxValue, value, false); 

con la seguente: 

builder . setProgress (0, 0, false); 

Il risultato è mostrato nella Figura 9.17. 
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This is a Notification for a progress of indeterm.. 



Figura 9.17 II task di tipo indeterminate. 



Notifiche con layout personalizzato 

Sebbene quelle descritte soddisfino la maggior parte degli scenari, in alcuni casi potrebbe essere 
necessario creare delle notifiche con dei layout personalizzati. E un'operazione molto semplice grazie 
all'utilizzo della classe Remoteviews, che permette a un'applicazione di creare un layout che potrà poi 
essere usato da un'altra applicazione. Il concetto è simile a quello dei Pendingintent solamente che è 
applicato alle varie view. Creare un oggetto di questo tipo e impostarlo come contenuto di una 
notifica è cosa molto semplice, come possiamo vedere nel nostro esempio: 

private void showCustomLayoutNotif ication ( ) { 
final String oontentText = getResources ( ) 

. get String (R. string . custom_layout_text ) ; 
final String oontentTitle = getResources ( ) 

. get String (R. string . oustom_layout_title) ; 
final Remoteviews customViews = new Remoteviews (getPackageName ( ) , 

R. layout . custom_notif ication) ; 
final Notif icationCompat . Builder builder = 

new Notif icationCompat . Builder (this) 

. setSmallIcon (R. drawable . ic_launcher) 

. setContentTitle (contentTitle) 

. setContent (customViews) ; 
mNotif icationManager. notif y(CUSTOM_LAYOUT_NOTIFICATION, builder . build ( ) ) ; 

} 

Vediamo infatti come sia facile creare una Remoteview a partire da un documento di layout e poi 



401 



visualizzarla all'interno della notifica attraverso l'invocazione del metodo letcontent o per ottenere il 
risultato nella Figura 9.18. 



10:26 MER 10 LUGLIO 
Custom layout Notification 




Figura 9.18 Esempio di layout personalizzato. 

Si tratta di un layout elementare contenente solamente una Textview, ma potrebbe essere anche 
più complesso con qualche limitazione che dipende dalla versione della piattaforma e per la quale 
rimandiamo alla documentazione ufficiale. 



Altre modalità di notifica 

Oltre a queste informazioni obbligatorie esiste la possibilità di associare a una notifica un particolare 
suono. Per farlo si può modificare il valore dell'attributo pubblico chiamato defauits della notifica 
attraverso l'istruzione 

notif ication . defauits = notif ication . defauits | Notif ication . DEFAULT_SOUND 

che abilita come suono quello predefinito. Nel caso in cui si volesse specificare un suono diverso 
sarà sufficiente valorizzare l'attributo pubblico sound, di tipo uri, che è un riferimento al medium da 
riprodurre. Nel caso in cui volessimo ripetere l'esecuzione del medium fino alla esplicita eliminazione 
della notifica da parte dell'utente, potremmo applicare anche il flag associato alla costante 
Notif ication. flag_insistent. E bene sottolineare come l'impostazione del suono attraverso 
l'attributo defauits sovrascriva l'eventuale impostazione dell'attributo sound. 

Un esempio di applicazione del suono può essere il seguente: 

public void showSoundNotif ication ( ) { 

final String contentText = getResources (). getString (R . string . sound_title) ; 
final String contentTitle = getResources (). getString (R. string . sound_title) ; 
Notification notification = new Notif icationCompat . Builder (this ) 

. setSmallIcon (R . drawable . ic_launcher ) . setContentText (contentText ) 

. setContentTitle (contentTitle) .build () ; 
notif ication. defauits = notif ication. defauits | Notification . DEFAULT_SOUND 

| Notif ication. FLAG_INSISTENT; 
mNotif ìcationManager .notify (SOUND_NOTIFICATION, notification) ; 

} 

dove abbiamo evidenziato la parte di interesse. 

Analogamente a quanto visto per il suono è possibile impostare alcune grandezze relativamente 
all'eventuale vibrazione del dispositivo come conseguenza della ricezione della notifica. Anche in 
questo caso si può agire sull'attributo defauits come segue: 

notif ication. defauits |= Notif ication . DEFAULT_VIBRATE 

che abbiamo questa volta espresso nella forma sintetica utilizzando l'operatore i = . Questa volta 
l'attributo pubblico per la personalizzazione delle informazioni di vibrazione si chiama vibrate e il 
valore corrispondente è un array di long, i quali rappresentano, espressi in millisecondi, il delay 
relativo alla prima vibrazione, la sua durata e quindi eventuali coppie di informazioni dello stesso tipo 
relativamente a delay e durata delle vibrazioni successive. Per esempio, le seguenti istruzioni 

long[] vìbrateData = {100,100,200,200}; 
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notification . vibrate = vibrateData; 

permettono di far vibrare per 200 millisecondi il dispositivo 100 millisecondi dopo la notifica, 
attendere 200 millisecondi e poi tarlo vibrare per altri 200. Sono informazioni che possono essere 
lunghe a piacere, anche se vanno utilizzate con criterio. È bene ricordare che la vibrazione di default 
impostata attraverso il flag default_vibrate si sovrappone a quella latta attraverso l'attributo 
vibrate. Anche in questo caso abbiamo realizzato un esempio: 

public void showVibroNotif ication ( ) { 

final String contentText = getResources ( ) . getString (R . string . vibro_title) ; 
final String contentTitle = getResources (). getString (R. string . vibro_title) ; 
Notification notification = new Notif icationCompat . Builder (this ) 

. set Smalli con (R . drawable . ic_launcher ) . set ContentText (contentText) 

. set ContentTitle (contentTitle) . build ( ) ; 
notif ication. defaults = notif ication. defaults | Notification . DEFAULT_VIBRATE 

| Notif ication. FLAG_INSISTENT; 
notif ication. vibrate = new long[] {100L, 100L, 200L, 200L}; 
mNotif icationManager .notif y (VIBRO_NOTIFICATION, notification) ; 

} 

L'ultima modalità di notifica prevede il controllo degli eventuali led attraverso questa impostazione: 

notification. defaults |= Notif ication . DEFAULT_LIGHTS 

Nel caso di una configurazione personalizzata, gli attributi possibili da impostare potrebbero invece 
essere i seguenti 

notification. ledARGB = OxffOOffOO; 
notification. ledOnMS = 500; 
notification. ledOffMS = 800; 

notification. flags |= Notif ication . FLAG_SHOW_LIGHTS; 

i quali indicano, rispettivamente, il colore da utilizzare, la durata relativa all'accensione e quella 
relativa allo spegnimento dei led durante il lampeggiamento abilitato attraverso il flag 
flag_show_lights. L'esempio da noi realizzato è il seguente: 

public void showLightNotif ication ( ) { 

final String contentText = getResources (). getString (R . string . light_title) ; 
final String contentTitle = getResources (). getString (R. string . light_title) ; 
Notification notification = new Notif icationCompat . Builder (this ) 

. set Smalli con (R . drawable . ic_launcher ) . set ContentText (contentText) 

. set ContentTitle (contentTitle) . build ( ) ; 
notif ication. defaults = notif ication. defaults | Notification . DEFAULT_VIBRATE 

| Notif ication. FLAG_INSISTENT; 
notif ication . ledARGB = OxffOOffOO; 
notif ication . ledOnMS = 500; 
notification. ledOffMS = 800; 

notification . flags | = Notification . FLAG_SHOW_L I GHT S ; 

mNotif icationManager . notif y ( L I GHT_NOT IF I CAT I ON , notification) ; 

} 

Oltre che fare la stessa considerazione precedente relativamente alle priorità dei flag, è bene 
precisare come non tutti i dispositivi siano in grado di fornire tutte le tonalità di colore richieste. 
Questo tipo di notifiche, poi, funzionano solamente quando il dispositivo non ha il display acceso, per 
cui abbiamo riportato l'esempio solo per completezza, anche se sarà difficile da testare se non 
lanciando delle notifiche in differita, come potremo fare dopo aver concluso il presente capitolo. 



I servi ce 

Nei paragrafi precedenti abbiamo visto come eseguire delle operazioni in background attraverso la 
creazione di thread, che però sono legati alla particolare activity all'interno della quale vengono 
definiti. Da quanto visto nel Capitolo 3 sappiamo che Android non garantisce che una particolare 
attività venga sempre mantenuta viva specialmente se non è visualizzata in un particolare momento. 
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Questo fa sì che l'activity non sia il luogo migliore dove descrivere operazioni, di lunga durata, da 
eseguire in background. A tal scopo, Android fornisce un tipo particolare di componente, anch'esso 
descritto da una specializzazione della classe context, che si chiama service e che ha un trattamento 
particolare che lo preserva dall'essere eliminato dal sistema se non in casi estremi In condizioni 
normali, un particolare service vuole essere la soluzione di due casi d'uso ben precisi II primo è 
quello che permette l'esecuzione di un task di lunga durata in modo indipendente dal ciclo di vita del 
componente che lo ha avviato. Per capire meglio, supponiamo di voler scaricare un file di grosse 
dimensioni all'interno del file system del dispositivo (o nella SD Card). Una prima soluzione, in base a 
quelle che sono le nostre conoscenze fino a questo momento, potrebbe essere quella di creare un 
thread all'interno dell' activity attraverso la quale l'utente ha potuto inserite l'URL del documento e poi 
premere il pulsante per l'avvio del download. Nel caso in cui vi fosse una particolare interazione con 
la UI per la visualizzazione, per esempio, di una barra di avanzamento, un'altra alternativa poteva 
essere la creazione di un AsyncTask. In teoria tutto potrebbe andare bene se non fosse per il fatto che 
sia il ciclo di vita del thread sia quello dell' AsyncTask sarebbero strettamente legati a quello 
dell' activity. Questo significa che se l'utente, avviato il download, preme il pulsante Back per uscire 
dall'applicazione (e quindi dall' activity stessa), il sistema potrebbe decidere con molta probabilità di 
interrompere e distruggere quanto avviato. Questo scenario è il primo che trova la propria soluzione 
nell' utilizzo di un service che si dice di tipo Started. Questo particolare tipo di servizio viene avviato 
attraverso il seguente metodo della classe context: 

public abstract ComponentName startService ( Intent service) 

Per questo tipo di servizi valgono le stesse regole di intent resolution che abbiamo descritto per le 
activity. Questo consente alla nostra attività di avvio del download di lanciare F intent corrispondente e 
anche terminare sapendo che comunque il sistema garantirà l'esecuzione del servizio almeno fino al 
completamento del task. Successivamente vedremo quali sono i metodi di callback da implementare 
per un service di tipo Started; per il momento è di fondamentale importanza capire quando il servizio 
viene effettivamente eliminato. Come già accennato, lo scenario descritto prevede che l'unico in grado 
di sapere se il task sia stato completato oppure no è proprio il servizio, che sarà anche responsabile 
della sua eliminazione attraverso l'invocazione di uno dei seguenti metodi 

public final void stopSelf() 

public final boolean stopSelf Result ( int startld) 

Nel caso in cui la responsabilità di terminare il servizio fosse esterna, il metodo da invocare 
sarebbe questo: 

public abstract boolean stopService ( Intent service) 

Da quanto visto in relazione ai metodi startService o e stopService o notiamo come il 
meccanismo sia lo stesso che abbiamo utilizzato nell'avvio di un' activity. Indipendentemente dallo 
stato del componente client, si tratta comunque del lancio di un particolare intent dopo il quale il client 
stesso potrebbe anche terminare la propria esistenza senza influire sull'esecuzione del task. Ultima 
considerazione riguarda il fatto che i metodi startService ( ) e stopService ( ) non sono simmetrici 
nel senso che il primo potrebbe essere invocato moltissime volte. Indipendentemente dal numero di 
volte in cui il metodo startService o è stato invocato, una sola chiamata a stopService o provoca 
la termiazione del servizio. 

Il secondo scenario per l'utilizzo di un servizio prevede che lo stesso esponga un'interfaccia che in 
ambito enterprise definiremo remota, inquanto in esecuzione di un processo diverso da quello del 
client. Questo tipo di servizi viene indicato come Bound, poiché il suo utilizzo presuppone che il client 
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ne abbia ottenuto un riferimento attraverso la seguente operazione 

public abstract boolean bindServìce ( Intent servìce, ServiceConnection conn, int flags) 

per poi liberarsene attraverso l'invocazione del metodo 

public abstract void unbindService (ServiceConnection conn) 

In questo caso è il client che sa quando inizia e quando finisce l'utilizzo delle operazioni messe a 
disposizione dal service. A differenza di prima, le operazioni di bind e unbind sono bilanciate e a esse 
è legato il ciclo di vita del servizio stesso. L'istanza di service viene infatti distrutta non appena tutti i 
componenti hanno eseguito V unbind. In sintesi, se il servizio serve a qualche componente viene 
mantenuto attivo, mentre viene distrutto se non serve più a nessuno. Questo permette un utilizzo 
ottimale di tutte le risorse del dispositivo. Le modalità di utilizzo di un servizio ci consentono di poterlo 
sfruttare anche se il client appartiene a un'applicazione diversa. Per un service Started, per esempio, 
un'applicazione potrebbe lanciare l'intent corrispondente e quindi accedere alle funzionalità del 
servizio. Analogamente, un qualunque client potrebbe invocare il metodo bindService ( ) passando il 
corretto intent e ottenere il riferimento all'interfaccia remota per l'accesso alle funzionalità esportate; 
questo anche se in un' app Reazione, e quindi processo, diversi 

NOTA 

Un service è inizialmente pubblico ma è possibile limitarne la visibilità attraverso un opportuno 
attributo in fase di dichiarazione nel file AndroidManifest.xmi di configurazione. 

Prima di descrivere nel dettaglio le due tipologie di servizio, Started e Bounded, è sicuramente 
utile fare un breve riassunto di quelle che sono le regole di creazione e distruzione delle istanze 
corrispondenti Diciamo subito che quando parliamo di "esecuzione del servizio" intendiamo 
l'esistenza di una sua istanza sulla quale non è stato ancora invocato il metodo onDestroy ( ) . 
Supponiamo che non esista alcuna istanza e che un client invochi il metodo startservice ( ) . Qui 
viene creata un'istanza del servizio (che vedremo essere una specializzazione della classe service) 
fino a che il servizio stesso non invoca uno dei metodi stopseif ( ) oppure se un altro client invoca il 
metodo stopservice ( ) . Un aspetto spesso trascurato consiste nel fatto che una stessa istanza di 
service potrebbe essere sia Started che Bounded. Questo significa che se un servizio è già attivo a 
seguito di una richiesta come Started, e un client ne richiede l'utilizzo attraverso il metodo 
bindServìce ( ) , non viene creata una nuova istanza ma utilizzata quella già esistente. Inoltre se un 
processo avviato come Started invoca uno dei metodi stopseif ( ) oppure un altro client invoca il 
metodo stopservice ( ) , non viene distrutto se comunque vi è un bind attivo. 

Sono concetti fondamentali al fine di un utilizzo ottimale di tutte le risorse. È infatti una cattiva 
abitudine lasciare in esecuzione dei servizi che non vengono utilizzati da alcun client. Quando si 
sviluppa un particolare servizio è quindi buona norma pensare sempre alle politiche di interruzione, 
che nel caso di servizi di tipo Bound sono abbastanza immediate ma che possono essere complicate 
nel caso di servizi di tipo Started. 

Creazione di un service 

Creare un particolare service significa creare una specializzazione della omonima classe eseguendo 
l'override di alcuni metodi di callback la cui chiamata dipende dal tipo di servizio. Per quello che 
riguarda il ciclo di vita dei service Started possiamo osservare la Figura 9.19, mentre per il service 
Bound il ciclo di vita è quello nella Figura 9.20. 
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Figura 9.19 Ciclo di vita di un service di tipo Started. 
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Figura 9.20 Ciclo di vita di un service Bound. 

Abbiamo più volte detto che quando un servizio non è in esecuzione e arriva una richiesta 
attraverso l'invocazione del metodo startservice o , il sistema ne crea un' istanza invocando 
successivamente il metodo 

public void onCreateO 



Si tratta del metodo che dovrà essere implementato per entrambi i tipi di servizio in quanto 
invocato in corrispondenza del primo utilizzo. In questo metodo vi sarà tutto il codice di 
inizializzazione dei componenti utilizzati dal servizio. Questo metodo non verrebbe invocato nel caso in 
cui una nuova richiesta arrivasse con il servizio già attivo. Il metodo di callback che invece viene 
sempre invocato a ogni richiesta di accesso al servizio tramite l'invocazione del metodo 
startService ( ) è il seguente: 

public int onStartCommand (Intent intent, int flags, int startld) 

È un metodo che non dovremo mai invocare in modo esplicito ma che verrà invocato dal sistema 
passando come primo parametro il riferimento all' intent utilizzato nel metodo startservice o . In 
questa fase è importante fare attenzione al fatto che l'intent potrebbe anche arrivare nuli. 
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È il caso in cui il servizio fosse stato interrotto e quindi riavviato in modo automatico dal sistema. Il 
secondo parametro contiene una serie di flag che ci danno appunto le informazioni per capire se il 
metodo è stato eseguito normalmente oppure dopo una precedente interruzione. Il terzo parametro è 
molto importante perché rappresenta un identificatore unico della richiesta. È un valore intero che si 
può poi utilizzare nel seguente overload del metodo di interruzione: 

public final boolean stopSelf Result ( int startld) 

il quale permette appunto di chiudere il servizio solamente nel caso in cui l'esecuzione più recente 
avesse avuto come identificatore quello passato come parametro. Sono comunque situazioni 
abbastanza rare che non tratteremo in questa sede. 

Un altro aspetto molto importante riguarda il significato del valore di ritomo di tipo intero del 
metodo onStartCommand ( ) , che è un'indicazione di come il servizio si dovrà comportare nel caso il 
sistema decidesse di eliminarlo prematuramente (dopo che il metodo stesso si è concluso). I possibili 
valori al momento sono quelli associati alle seguenti costanti della classe Service: 

Service . START_NOT_STICKY 

Service . S TART_S T I CK Y 

Service . START_REDELIVER_INTENT 

Se il valore ritornato è quello descritto dalla costante start_not_sticky il servizio, in caso di 
eliminazione da parte del sistema, non verrà riawiato successivamente a meno che non vi siano altre 
richieste da esaudire. Qui la richiesta corrispondente verrà in un certo senso persa, e sarà 
responsabilità dell'applicazione provvedere eventualmente a inviare una nuova richiesta attraverso il 
metodo startservice ( ) . Un esempio è quello relativo a un servizio di sincronizzazione. Nel caso in 
cui questo dovesse fallire non sarebbe un problema in quanto potrebbe essere eseguito 
successivamente dopo un'esplicita richiesta da parte dell'utente oppure a un successivo evento di 
scheduling. 

Se il valore di ritorno è invece start_sticky il sistema, in caso di interruzione dopo la conclusione 
del metodo onStartCommand ( ) , invocherà nuovamente il metodo senza però passare il riferimento 
all'intent, che questa volta sarà nuli. Questo nel caso in cui non vi fossero altre richieste con altri 
intent per i quali il comportamento sarebbe comunque indipendente. Lo scenario di utilizzo è quello di 
servizi che devono avviare e poi interrompere task molto lunghi, come potrebbe essere quello relativo 
all'avvio o interruzione di un player musicale. 

Infine, se il valore di ritomo è quello associato alla costante start_redelivery_intent il sistema si 
preoccuperà di riprogrammare e reinviare l' intent invocando con esso nuovamente il metodo 
onStartCommand ( ) . È importante sottolineare che l'intent rimarrà programmato fino a che non si 
invocherà il metodo stopseifresuit o passando come parametro l'identificatore corrispondente. 

Abbiamo visto come il metodo oncreate ( ) sia specifico di entrambi i tipi di servizio, mentre il 
metodo onStartCommand ( ) sia caratteristico solo di quelli Started. Nel caso dei servizi Bound si 
dovrà fornire un'implementazione del metodo: 

public abstract IBinder onBind ( Intent intent) 

che ricordiamo essere invocato in corrispondenza dell'esecuzione del metodo fcindservice ( ) da 
parte del client. Come vedremo questa modalità di interazione è asincrona e il valore di ritorno sarà 
una particolare implementazione dell'interfaccia iBinder. Il concetto legato a questo tipo di servizi è 
molto diverso da quello relativo ai servizi Started. Ora infatti quello che si ottiene è un riferimento a 
un oggetto che espone un'interfaccia, che possiamo definire remota, che ci permette di accedere a 
particolari funzionalità che possono essere implementate in un'applicazione diversa rispetto alla 
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nostra. È come se il servizio rappresentasse un oggetto condiviso tra più applicazioni. 
NOTA 

Volendo fare un'analogia con il concetto di content provider potremmo dice che, mentre questo 
consente la condivisione di informazioni e quindi dati, un service di tipo Bound permette una 

condivisione di logica in quanto espone delle operazioni. 

Quando realizzeremo un servizio di tipo Bound vedremo come descrivere, attraverso un 
documento AIDL (Android Interface Definition Language), le operazioni dell'interfaccia del nostro 
servizio e la relativa implementazione che poi utilizzeremo come valore di ritorno del metodo 
onBind ( ) . Nel caso in cui il servizio fosse Started il valore di ritorno del metodo onBind ( ) potrà 
quindi essere nuli. Notiamo inoltre come, mentre il metodo onstartcommando non è compreso nel 
ciclo di vita di un servizio Bound, il metodo onBind ( ) non è compreso nel ciclo di vita di un servizio 
Started. 

Sempre osservando il ciclo di vita di un servizio di tipo Bound, rileviamo la presenza del metodo 

public boolean onUnbind ( Intent intent) 

che viene invocato quanto tutti i client sono disconnessi e quindi il servizio è nelle condizioni di 
poter essere eliminato. 
NOTA 

L'ultima è un'affermazione che non tiene conto del fatto che allo stesso servizio si potrebbe 
accedere anche nella modalità Started. In quel caso il servizio non verrà eliminato fintantoché non 
saranno stati elaborati anche tutti i corrispondenti intent. 

Il valore di ritorno di tipo boolean ci permette di decidere se, in corrispondenza di un'operazione 
di bindservice ( ) successiva, si debba o meno ricevere una notifica attraverso l'invocazione del 
metodo 

public void onRebind (Intent intent) 

dove il parametro è l' intent utilizzato nell'operazione di bind. 

L'ultimo metodo di cui potremo fare Yoverride e che appartiene a entrambi i cicli di vita è quello 
che viene invocato per notificare la eliminazione del servizio, ovvero 

public void onDestroyO 

Si tratta dell'etimo metodo invocato per un particolare istanza di un servizio, un'occasione per 
liberare tutte le eventuali risorse acquisite comprese le eventuali sottoscrizioni come listener di 

BroadcastReceiver 0 altri Servizi. 

Abbiamo già descritto come la modalità di eliminazione del servizio dipenda da diversi fattori legati 
sicuramente al tipo ma anche ad altri aspetti che vengono fortunatamente gestiti dal sistema. Per 
esempio, un service di tipo Bound collegato a un'activity che è attiva in un particolare momento avrà 
meno probabilità di essere eliminato di imo legato a componenti non visibili Viceversa, un service di 
tipo Started in esecuzione da molto tempo ha ima probabilità maggiore di essere eliminato rispetto ad 
altri. Per questo motivo è sempre bene studiare in modo preciso il comportamento del servizio nel 
caso in cui il sistema decidesse di eliminarlo. 

Dopo aver creato la particolare specializzazione, diretta o indiretta, della classe service, il passo 
successivo consiste nella sua definizione all'interno del file di configurazione AndroidManif est . xml 
attraverso l'utilizzo dell'elemento <service/> come figlio diretto dell'elemento <appiication/>. 
Quello di nome android marne è l'unico attributo obbligatorio e, come avviene per le activity, ha come 
valore il nome della classe che lo implementa. Per un elenco degli attributi rimandiamo alla 
documentazione ufficiale. In questa occasione sottolineiamo semplicemente il fatto che, come per le 
activity, anche per l'avvio dei service si può utilizzare degli intent espliciti oppure degli intent a cui 
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vengono applicate le stesse regole di intent resolution già viste. A tal proposito un aspetto molto 
importante riguarda la visibilità del servizio. Nel caso in cui il servizio fosse locale di una singola 
applicazione Fintent da utilizzare può essere esplicito, a differenza di un servizio pubblico per il quale 
l'unica modalità possibile è quella che prevede la definizione di un intent con azione, category ed 
eventualmente dei dati. A livello di definizione è importante utilizzare l'attributo android: exported 
che, nel caso di un valore false, rende il servizio privato. Un esempio di definizione di un servizio 
pubblico in grado di essere attivato a seguito del lancio di un particolare intent potrebbe essere 
questo: 

<service android :name=" co.uk. max. ImageDownloadService" 
android: exported="true" > 

<intent-f ilter> 

<action android : name=" co . uk . max . action . DOWNLOAD_ACTION" /> 
<category android : name=" co . uk . max . category . DOWNLOAD_CATEGORY" /> 

</ intent-f ilter> 

<intent-f ilter> 

<action android : name=" co . uk . max . action . DELETE_ACTION " /> 
-ccategory android: name=" co .uk .max . category . DOWNLOAD_CATEGORY" /> 

</ intent-f ilter> 
</service> 

È quindi un servizio che potrebbe essere avviato da un intent del seguente tipo 

final Intent intent = new Intent (this, " co . uk .max . action . DELETE_ACTION" ) ; 
intent . addCategory (" co . uk .max . category . DOWNLOAD_CATEGORY" ) ; 
startService (intent) ; 

come avremo modo divedere nel dettaglio nei paragrafi successivi 

Esempio di service di tipo Started 

A questo punto vogliamo utilizzare quanto imparato per gestire alcune funzionalità della nostra 
applicazione UGHO, e in particolare vogliamo gestire l'invio delle informazioni al server. E infatti imo 
scenario che ben si sposa con la creazione di un service di tipo Started, in quanto si tratta di un task 
che può essere eseguito in background al termine del quale il servizio stesso può essere eliminato. 
Come accennato in precedenza, è qualcosa di relativamente semplice che nasconde però delle insidie 
legate al fatto che, di default, i metodi del servizio vengono eseguiti all'interno dello stesso thread del 
chiamante. Questo significa che per raggiungere il nostro scopo di eseguire il task in background, è 
necessario implementare qualche accorgimento che utilizza comunque concetti già visti all'inizio di 
questo capitolo. 

In questo momento non trattiamo l'esecuzione della richiesta HTTP vera e propria per l'invio delle 
informazioni in quanto sarà argomento del prossimo capitolo. Quello che vogliamo fare è invece 
creare l'infrastruttura che ci permetterà di eseguire tale richiesta all'interno di un servizio nel modo più 
corretto e affidabile possibile. 

Il primo passo consiste nel definire l'interfaccia verso questo servizio, ovvero il come dovrà essere 
fatto Fintent da lanciare attraverso il metodo startService ( ) . E bene incapsulare queste informazioni 
all'interno di ima classe di utilità, che nel nostro caso abbiamo chiamato serviceutu e abbiamo 
inserito nel package s ervice . impl relativamente a quello dell'applicazione. Come possiamo vedere 
dal codice che segue, si tratta di una classe molto semplice che definisce le costanti per l'azione di 
invio e per la category. Abbiamo poi definito un meccanismo che consente di costruire Fintent da 
lanciare senza specificare alcun parametro di input. Ma come facciamo a inviare le informazioni 
relative ai LocaiDataModei se non li passiamo come parametri attraverso degli extra? Dobbiamo 
semplicemente ricordarci che le informazioni sono salvate all'interno del DB per cui il servizio non 
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dovrà fere altro che andare a leggere i dati dal DB locale e quindi inviarli al server. Serve un 
meccanismo che ci permetta di distinguere le informazioni già inviate con successo da quelle invece 
non inviate, per cui abbiamo bisogno di una colonna in più che chiamiamo sync, che conterrà appunto 
lo stato di sincronizzazione del dato. L'aggiornamento del DB è ora molto semplice in quanto, nel 
Capitolo 8, abbiamo utilizzato il componente descritto dalla classe HoroOpenHelper. Non dovremo 
infatti fare altro che cambiare lo script di creazione del DB come segue: 

CREATE TABLE HORO_VOTE ( 

_id integer PRIMARY KEY AUTO INCREMENT UNIQUE, 

entry_date date NOT NULL UNIQUE, 

love_vote integer NOT NULL, 

health_vote integer NOT NULL, 

work_vote integer NOT NULL, 

luck_vote integer NOT NULL, 

horo_sign text NOT NULL, 

sync text, 

location text) ; 

CREATE INDEX UNIQUE_ENTRY_DATE ON HORO_VOTE (_id, entry_date) ; 

oltre ad aggiornare il valore per la versione del DB nella classe ughoDB nel seguente modo: 

public final class UghoDB { 

public static final String DB_NAME = "UghoDB"; 
public static final int DB_VERSION = 2; 



public static final String SYNC = "sync"; 

} 

Notiamo anche l'aggiunta della costante relativa alla nuova colonna che conterrà lo stato di 
sincronizzazione. 
NOTA 

Nel nostro caso il valore di versione precedente era 1 per cui siamo passati a 2. Il lettore potrebbe 
avere un valore di versione diverso. Altra osservazione riguarda il fatto che il campo sync può 

assumere anche il valore nuli, per cui potrebbe benissimo essere utilizzato come Nuli Column 
Hack. 

Il metodo di Factory per la creazione dell' intent di sincronizzazione potrebbe essere questo: 

public static Intent create () { 

final Intent servicelntent = new Intent (SEND_DATA_ACTION) ; 
servicelntent . addCategory (HOROSCOPE_CATEGORY) ; 
return servicelntent; 

} 

Un lettore attento potrebbe osservare come in questo intent non vi sia nulla di dinamico, per cui è 
qualcosa che può essere creato una volta sola e quindi essere gestito come costante statica. La nostra 
classe di utilità diventa allora la seguente: 

public final class ServiceUtil { 

private static final String HOROSCOPE_CATEGORY = Const.PKG 
+ " . category . HOROSCOPE_CATEGORY" ; 

private static final String SEND_DATA_ACTION = Const.PKG 
+ " . action . SEND_DATA_ACTION" ; 

public static final Intent SYNC_INTENT = new Intent (SEND_DATA_ACTION) ; 

static { 

SYNC_INTENT . addCategory (HOROSCOPE_CATEGORY) ; 

} 
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private ServiceUtil ( ) { 

throw new AssertionError ( "Never instantiate me! ìm an " + 
"utility class! !") ; 

} 

} 

L'istruzione per il lancio del servizio diventa banale, ovvero: 

startService (ServiceUtil . INTENT) ; 

A tal proposito il nostro servizio, che descriveremo all'interno di diverse specializzazione della 
classe Service e che qui indicheremo genericamente come syncservice, dovrà essere dichiarato nel 

file AndroidManifest .xml COme Segue: 

<service android: name=" . servi ce . impl . SyncService" andrò id : exported=" f alse"> 
<intent-f ilter> 

<action android:name="uk.co.massim. . . action . SEND_DATA_ACTION" /> 
<category android : name="uk . co . massim . . . category . HOROSCOPE_CATEGORY" /> 
</ intent-f ilter> 
</ service> 

dove abbiamo ancora abbreviato i valori di action e category per motivi di spazio, ma che 
Dovranno corrispondere a quelli specificati in ServiceUtil. 

Come detto la richiesta vera e propria al server verrà gestita nel prossimo capitolo, quando 
tratteremo appunto la gestione della sicurezza e del networking. Andremo infatti a implementare in 
modo corretto la classe RestManager, che in questa fase abbiamo simulato nel seguente modo: 

public final class RestManager { 

private RestManager)) { 

throw new AssertionError ( "Never instantiate me! "); 

} 

public static void sendLocalData ( final LocalDataModel localData) 

throws IOException { 
// TODO: finora abbiamo solo simulato l'attesa 
try { 

Thread.sleep (300L) ; 
} catch (InterruptedException ie) {} 

} 

} 

Inquest sede incapsuliamo invece il task da eseguire all'interno di un altro metodo di utilità di una 
classe che questa volta chiamiamo syncronizer e che poi nel servizio utilizzeremo semplicemente 
come client. Questa implementazione ci permetterà anche di introdurre un concetto molto importante 
per l'interazione con un content provider, ovvero l'esecuzione di istruzioni in batch: 

public final class Synchronizer { 

public static final String TAG_LOG = Synchronizer . class . getName () ; 

public static final String SYNC_VALUE = "YES"; 

private Synchronizer ( ) { 

throw new AssertionError ( "Never instantiate me!"); 

} 

public static void syncLocalData (final Context context) { 

final ContentResolver contentResolver = context . getContentResolver () ; 
final String where = new StringBuilder (UghoDB . HoroVote . SYNC) 

.append(" IS NULL " ) . toString ( ) ; 
final Cursor toUpdateCursor = contentResolver 

. query (UghoDB . HoroVote . CONTENT_URI , nuli, where, nuli, nuli); 
ArrayList<ContentProviderOperation> operations = 
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new ArrayList<ContentProviderOperation> (toUpdateCursor .getCount () ) ; 

final String idSelector = new StringBuilder (UghoDB . HoroVote ._ID) 

.append(" = ? " ) . toStrìng ( ) ; 
while (toUpdateCursor .moveToNext () ) { 

final LocalDataModel localData = 

LocalDataModel . f romCursor (toUpdateCursor) ; 

try { 

RestManager . sendLocalData (localData) ; 
final String [ ] idSelectorArgs = 

new String [ ] { String . valueOf (localData . id) } ; 
operations . add (ContentProviderOperation 

. newUpdate (UghoDB . HoroVote . CONTENT_URI ) 

. withValue (UghoDB . HoroVote . SYNC, SYNC_VALUE) 

.withSelection (idSelector, idSelectorArgs) 

.withYieldAllowed(true) .build() ) ; 
Log . d ( TAG_LOG , "Added update operation for id " + localData . id) ; 
} catch (IOException e) { 
e .printStackTrace () ; 

} 

} 

toUpdateCursor . close ( ) ; 
try { 

contentResolver . applyBatch (UghoDB . AUTHORITY, operations) ; 

} catch (RemoteException e) { 
e . printStackTrace ( ) ; 

Log . e (TAG_LOG, "Error applying batch for sync update!", e); 
} catch (OperationApplicationException e) { 
e . printStackTrace ( ) ; 

Log . e (TAG_LOG, "Error applying batch for sync update!", e); 

} 

} 

} 

Come possiamo notare, il metodo inizia con una query che consente di estrarre tutte le informazioni 
per le quali il campo sync non assume il valore YES, che corrisponde appunto all'avvenuta 
sincronizzazione. Il risultato sarà un Cursor contenente, se ve ne sono, l'insieme dei record da 
sincronizzare. Attraverso il metodo getcount ( ) del cursore ci informiamo sul numero di questi record 
per allocare un'ArrayList di dimensione sufficiente a contenere un numero di oggetti di tipo 
ContentProviderOperation per aggiornare tutti i record. Si tratta infatti di un'astrazione di una 
qualunque query che è possibile eseguire su un content provider. All'interno di un ciclo while andiamo 
a invocare il metodo statico RestManager. sendLocalData (localData) per trasmettere al server 
l'informazione. L'operazione può avere successo oppure no. Nel primo caso non faremo altro che 
aggiungere all'elenco delle operazioni da eseguire sul content provider quella di aggiornamento del 
campo sync. Per farlo si utilizza il metodo newupdate o della stessa classe 

ContentProviderOperation. Da notare come si utilizzi il chaining per indicare TURI della tabella di 
riferimento, la coppia colonna- valore da aggiornare e quindi la clausola where con relativi valori dei 
placeholder: 

operations . add (ContentProviderOperation 

. newUpdate (UghoDB . HoroVote . CONTENT_URI ) 
.withValue (UghoDB . HoroVote . SYNC, SYNC_VALUE) 
.withSelection (idSelector, idSelectorArgs) 
.withYieldAllowed(true) .build() ) ; 

Molto importante è l'istruzione withYieidAiiowed o evidenziata nel frammento di codice 
precedente, che permette di abilitare quello che si chiama yield e che intende risolvere un problema 
che si ha nel caso dell'esecuzione massiva di query da parte di un processo su un content provider. 
Nel caso di molte query da parte di un processo, potrebbe infatti succedere che altri processi non 
riescano ad accedere al DB. Questa opzione consente invece ad altri processi di eseguire delle query, 
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di incunearsi, anche durante un'interazione massiva da parte di un processo 

contentResolver . applyBatch (UghoDB . AUTHORITY, operations) ; 

il quale non là altro che eseguire le operazioni di aggiornamento memorizzate in precedenza. 
Al momento disponiamo quindi di un metodo che permette di trasmettere al server le informazioni 
relative ai dati inseriti nel nostro DB locale aggiornando lo stato di sincronizzazione. 
NOTA 

Quello realizzato è un sistema di sincronizzazione molto semplificato che non tiene conto, per 
esempio, delle eventuali cancellazioni lato server o dell'utilizzo di identificatori diversi per le entità 
nel DB locale e le stesse in un'ipotetica base dati remota. 

Non ci resta che concentrarci sulla implementazione del nostro servizio che inizialmente chiamiamo 

BadSyncServicel 

public class BadSyncService extends Service { 
gOverride 

public int onStartCommand (Intent intent, int flags, int startld) { 
Synchronizer . syncLocalData (this) ; 
return START_STICKY; 

} 

SOverride 

public IBinder onBind ( Intent intent) { 
return nuli; 




Abbiamo esteso la classe Service ed eseguito Yoverrìde del metodo onStartCommand ( ) 
invocando il metodo s yncLocalData ( ) che abbiamo implementato in precedenza. Ma come mai 
questa è una pessima implementazione di Service? Il motivo principale consiste nel fatto che, come 
già detto, il metodo onstartcommando viene eseguito all'interno dello stesso thread dell'applicazione 
chiamante. 

NOTA 

Essendo un service di tipo Started notiamo come il valore di ritorno del metodo onBind o sia mai. Tale 
metodo è astratto nella classe service e deve comunque essere implementato nelle diverse 
realizzazioni concrete. 

Un'implementazione di questo tipo rende quasi inutile l' implementazione di un servizio ed è un collo 
di bottiglia che può portare al blocco della UI con conseguente errore diANR (Application Not 
Responding). Una corretta implementazione del metodo onStartCommand ( ) dovrebbe quindi 
semplicemente raccogliere le infromazioni necessarie e poi lanciare l'elaborazione del task a un altro 
thread. Questo ci ha permesso di creare una nuova implementazione di service che abbiamo 
chiamato ComplexSyncService e che utilizza alcuni dei concetti visti all'inizio di questo capitolo. Come 
fatto in un esercizio, ora il produttore è rappresentato dalla implementazione di service, mentre il 
consumatore è rappresentato da un thread che abbiamo definito attraverso una classe interna in 
questo modo: 

private final class ConsumerHandler extends Handler { 

public ConsumerHandler (Looper looper) { 
super (looper) ; 

} 

@Override 

public voìd handleMessage (Message msg) { 

Synchronizer . syncLocalData (ComplexSyncService . this ) ; 
stopSelf (msg . argl ) ; 
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} 

} 

Vediamo come si tratti di una classe interna che estende Handier e utilizza un looper che gli viene 
fornito da un'istanza della classe HandierThread che abbiamo inizializzato e avviato all'interno del 
metodo onCreate ( ) '. 
SOverride 

public void onCreate () { 
super . onCreate () ; 

HandlerThread handlerThread = new HandlerThread ( "ComplexSyncService" , 

Process . THREAD_PRIORITY_BACKGROUND) ; 
handlerThread. start ( ) ; 

mConsumerLooper = handlerThread. getLooper () ; 
mConsumerHandler = new ConsumerHandler (mConsumerLooper ) ; 

} 

Di nuovo, rispetto all'esempio realizzato in precedenza abbiamo l'utilizzo di una priorità 
caratterizzata dalla costante Process . thread_priority_background, che permette di informare il 
sistema che si tratta di un processo che non dovrebbe avere alcuna interazione con la UI. Tornando 
alla classe interna, vediamo come sia stato utilizzato il metodo stopseif o passando come parametro 
l'identificatore della particolare richiesta. È un accorgimento che ci consente di eliminare i servizi solo 
nel caso in cui efièttivamente non vi siano altri intent in coda e in attesa di essere soddisfatti 

Il metodo che comunque viene chiamato a ogni richiesta è il seguente: 

SOverride 

public int onStartCommand ( Intent intent, int flags, int startld) { 
Message msg = mConsumerHandler . obtainMessage () ; 
msg.argl = startld; 
mConsumerHandler . sendMessage (msg) ; 
return START_STICKY; 

} 

che notiamo essere ora molto snello. Usuo compito è semplicemente quello di estrarre le 
informazioni che servono dall' intent e creare il messaggio da inviare all'handler per la sua esecuzione 
nel thread associato. Queste sono quindi le uniche operazioni che vengono eseguite nel thread 
chiamante; il messaggio viene infatti eseguito nel thread associato all'oggetto HandlerThread definito 
nel metodo onCreate ( ) . 

A questo punto, dopo aver dichiarato il servizio nel documento di configurazione 

AndroidManifest.xml COme Segue 

<service android:name=" . service . impl . ComplexSyncService" androidi exported="false"> 
<intent-filter> 

<action android:name="uk.co.mas. . . action . SEND_DATA_ACTION" /> 
<category android : name="uk . co . mas . . . category . HOROSCOPE_CATEGORY" /> 
</intent-filter> 
</ service> 

individuiamo il punto in cui lanciare il servizio, ovvero il seguente metodo additem ( ) della classe 
NewDataFragment che contiene la logica di raccolta e salvataggio delle informazioni relative a una 
particolare data: 

private void addltem() { 

LocalDataModel newData = LocalDataModel . create ( 0 , 

mCurrentDate . getTimelnMìllis ( ) , (int) mLoveRatingBar . getRating ( ) , 

(int) mHealthRatingBar . getRating () , (int) mWorkRatingBar . getRating () , 

(int) mLuckRatingBar . getRating ( ) ) ; 
long newld = mDao . insertWithSign (newData, mUserZodiac . name ( ) ) ; 
if (newld > 0) { 

getActivity () . startService (ServiceUtil . SYNC_INTENT) ; 

} 

getActivity ( ) . finish ( ) ; 

} 
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Nel codice evidenziato notiamo come si provveda all'inserimento nel DB e all'avvio del service nel 
caso di successo. Nel caso in cui il dato non venisse inserito correttamente, il valore di ritomo 
sarebbe -1 e quindi non sarebbe necessaria un'operazione di sincronizzazione. 

Per verificarne il funzionamento consigliamo il lettore di eseguire l'applicazione con l'emulatore e 
quindi di esaminare il DB da riga di comando attraverso lo strumento sqlite3 che abbiamo imparato a 
utilizzare nel Capitolo 8, dedicato alla gestione dei dati. Consigliamo inoltre di inserire alcuni log in 
corrispondenza dei principali metodi di callback per esaminare il ciclo di vita del servizio. 

La classe IntentService 

L'esempio precedente descrive il caso più generico di service di tipo Started ma richiede 
comunque la conoscenza di alcuni concetti non banali, oltre che obbligare alla scrittura di diverse righe 
di codice. Per questo motivo è stata definita una particolare specializzazione di service che si chiama 
intentservice, che permette di ottenere lo stesso risultato in modo molto più semplice. Si tratta 
infatti di una classe a cui viene associato un thread nel quale vengono eseguite, una dopo l'altra, tutte 
le richieste invocate attraverso il metodo startservice o . Estendendo la classe IntentService non 
abbiamo la necessità di creare un thread diverso, in quanto ci viene regalato dall'implementazione 
stessa. Tutto ciò che dovremo fare sarà fornire un'implementazione del seguente metodo: 

protected void onHandlelntent ( Intent intent) 

Nel nostro caso abbiamo così implementato la classe intentsyncservice: 

public class IntentSyncService extends IntentService { 

public IntentSyncService ( ) { 

super ( "IntentSyncService" ) ; 

} 

SOverride 

protected void onHandlelntent (Intent intent) { 
Synchronizer . syncLocalData (this ) ; 

} 

} 

La nostra implementazione è banale, poiché contiene solamente la chiamata al nostro metodo di 
sincronizzazione. È bene comunque precisare che un IntentService delega l'esecuzione del proprio 
metodo onHandlelntent o a ununico thread che esegue le diverse chiamate una dopo l'altra. La 
gestione delle richieste su un pool di thread richiede un'implementazione specifica che prevede 
l'utilizzo di strumenti come gli Executor e implementazioni dell'interfaccia caiiabie. 

Service di tipo Bound 

Come abbiamo descritto sopra, un service di tipo Bound ha un significato diverso rispetto a imo di 
tipo Started sebbene ne possa condividere talvolta la classe. Per questo tipo di servizi è importante il 
concetto di bind, che consiste nell'ottenere un riferimento al servizio per poterne utilizzare le 
operazioni. A un' operazione di bind segue un'operazione di unbind. A differenza di un service di tipo 
Started, uno di tipo Bound viene poi eliminato nel momento in cui non vi sono più componenti che ne 
posseggono un riferimento (a meno che lo stesso service non sia tenuto in vita da una richiesta che lo 
utilizza come Started). 

Nella nostra applicazione UGHO non ci servono componenti di questo tipo per cui realizzeremo un 
esempio completamente indipendente che ci consentirà di implementare un cronometro. Faremo in 
modo che i servizi a cui un componente potrà accedere saranno relativi all'avvio, la pausa, il reset e 



416 



quindi la visualizzazione del tempo corrente. 

Sapendo che a ciascuna applicazione è associato un particolare processo, un obiettivo di quel tipo 
presuppone l'utilizzo di tecniche di Inter Process Communication (IPC). Nel mondo della 
programmazione distribuita non è qualcosa di molto originale. È sufficiente infatti pensare a tecnologie 
come RMI, CORBA o DCOM per comprendere come il tutto si basi sulla definizione di un insieme 
di interfacce con un linguaggio neutrale da cui, attraverso l'utilizzo di particolari strumenti, ottenere le 
API per la suddetta comunicazione. 

Realizzare un servizio di questo tipo non è comunque complicato e consiste fondamentalmente nei 
seguenti passi 

1 . Definizione dell'interfaccia attarverso AIDL. 

2. Parsing AIDL per la generazione degli stub. 

3 . Implementazione dell' interfaccia associata al servizio . 

4. Implementazione del servizio. 

A questo seguiranno la dichiarazione del servizio nel file di configurazione AndroidManif est . xml 
oltre che l'utilizzo dello stesso. 

Definizione dell'interfaccia AIDL e generazione degli Stub 

In precedenza abbiamo accennato a CORBA come tecnologia per la realizzazione di applicazioni 
distribuite. Essa permette la definizione di un insieme di funzionalità attraverso un linguaggio che 
prende il nome di Interface Definition Language (IDL). È un linguaggio con una sintassi molto 
vicina a quella di C che consente di descrivere l'insieme di operazioni che alcuni componenti sono in 
grado dimettere a disposizione di altri a essi remoti Dalla definizione dell'interfaccia IDL si passa 
quindi alla generazione, attraverso opportuni tool, di quelle che sono le API sia per l'accesso al 
servizio sia per la sua implementazione. Questo permette, per esempio, di implementare l'interfaccia 
in C++ e successivamente generarne un client in un altro linguaggio come Java. 

In generale nel mondo Java due oggetti si intendono remoti se sono in esecuzione in istanze diverse 
della JVM. Nel caso di Android il concetto è analogo, in quanto ciascuna applicazione viene eseguita 
all'interno di un proprio processo ottenuto attraverso l'esecuzione di una propria istanza della DVM. 
Come nel caso di CORBA, le operazioni che un componente remoto, in questo caso chiamato 
servizio, è in grado di eseguire vengono descritte attraverso un linguaggio detto Android IDL (AIDL); 
come vedremo nel successivo paragrafo, attraverso il tool aidl è possibile generare in modo 
automatico tutto il codice necessario. 

Un'interfaccia AIDL può descrivere più operazioni ciascuna delle quali può avere dei parametri di 
tipo primitivo o di tipo complesso, sia di input sia di output; mentre per i primi il passaggio delle 
informazioni avviene in modo automatico, per i secondi si richiede l'implementazione di una sorta di 
serializzazione che in ambito Android viene espressa attraverso l'interfaccia Parceiabie già vista nel 
Capitolo 8. In sintesi i tipi che si possono utilizzare all'interno di un'interfaccia AIDL sono i seguenti 

• tipi primitivi; 

• String e CharSequence; 

• tipi associati a interfaccia AIDL già presenti 

• tipi associati a Oggetti Parcelable. 

Un aspetto molto importante riguarda la modalità del passaggio: nel caso dei tipi generati a seguito 
di un'interfaccia AIDL avviene per riferimento, a differenza degli altri casi in cui il passaggio avviene 
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per valore. Questo significa che si può fere in modo che il servizio chiamato riceva in input il 
riferimento a un oggetto su cui invocare delle operazioni In questo modo è possibile implementare 
logiche di callback dal servizio ai relativi client. Un altro importante aspetto da sottolineare riguarda il 
latto che nel caso di oggetti Parceiabie oppure generati a partire da un'interfaccia AIDL, sia 
necessario importare i tipi corrispondenti in modo esplicito anche se appartenenti al loro stesso 
package. Nel caso in cui questi venissero poi utilizzati come parametri, sarà possibile specificare se di 
input, output o input/output, rispettivamente, utilizzando le parole chiave in, out o inout. Il lettore 
avrà sicuramente riconosciuto alcune analogie del meccanismo descritto con quelle che sono le 
caratteristiche diRMI (Remote Method Invocation). Anche in quel caso si può passare a un metodo 
il riferimento a uno stub generato attraverso il tool rmic per ottenere il passaggio di parametri per 
riferimento. Notiamo inoltre l'analogia tra il meccanismo diparceiabie e quello di serializzazione 
standard di Java, ritenuto probabilmente troppo dispendioso in termini di risorse. 
Oltre a quelli descritti, vi sono anche i seguenti tipi complessi, con alcune limitazioni: 

• List; 

• Map. 

Nel caso della List, gli elementi contenuti dovranno essere di uno dei tipi descritti in precedenza. E 
molto importante sottolineare come, al momento della ricostruzione di un parametro di questo tipo, 
l'implementazione utilizzata sia comunque un'ArrayList. Anche nel caso delle Map gli elementi 
contenuti, sia per le chiavi sia per i valori, dovranno essere del tipo elencato sopra, mentre il tipo 
dell'oggetto "ricostruito" sarà HashMap. Un'ultima differenza tra questi due tipi riguarda il fatto che per 
le List è possibile utilizzare anche una forma generica (per esempio List<integer>), mentre per le 
Map no. 

NOTA 

Purtroppo Android Studio al momento ha un bug che non permette la compilazione dei file AIDL, per 
cui descriveremo il progetto utilizzando il tool precedente, owero eclipse. Quando il bug verrà risolto 
dovrebbe essere comunque possibile compilare il progetto senza difficoltà copiando i file di 
estensione AIDL all'interno della cartella corrispondente in src/main/aidl. 

Non ci resta che mettere in pratica i concetti visti descrivendo quella che è l'interfaccia di un 
servizio che abbiamo chiamato ChronoService, la cui definizione è stata scritta nell'omonimo file con 
estensione .a idi: 

package uk . co . massimocarli . android. ohrono servi ce . servi ce; 

interface ChronoService { 

// Attiva il Chrono se non ancora fatto 
void start ( ) ; 

// Ferma il Chrono se non ancora fatto 
void stop ( ) ; 

// Resetta il Chrono 
void reset ( ) ; 

// Setta l'orario del Chrono 
void setTime (in long time) ; 

// Restituisce l'orario del Chrono 
long getTime ( ) ; 

} 

È un'interfaccia molto semplice che definisce alcuni metodi che ci consentiranno di interagire con il 
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servizio. Si tratta di un file che andiamo a posizionare all'interno della cartella dei sorgenti come se 
fosse un qualunque sorgente Java. 

Una volta definite le operazioni che il nostro servizio remoto dovrà fornire vediamo come il plug-in 
ADT esegua automaticamente il tool aidl nella cartella /platform-tools dell'ambiente, generando un 
sorgente Java di nome chronoservice all'interno della cartella dei file generati (Figura 9.21). 



^ChronoService 

▼ (2?src 

▼ {$} uk.co.massimocarli.android. chronoservice 

► [X] MainActivity.java 

▼ uk.co.massimocarli.android. chronoservice. service 
[5j ChronoService.aidl 

▼ ^gen [Generated Java Files] 

► {0 uk.co.massimocarli.android. chronoservice 

▼ Jj} uk.co.massimocarli.android. chronoservice. service 

► JT) ChronoService. java 

► ^Android 4.2.2 

► aftAndroid Dependencies 
§^assets 

► g^bin 

► &libs 

► &>res 

G AndroidManifest.xml 
2) icjauncher-web.png 
[i] proguard-project.txt 
[jj project.properties 



Figura 9.21 Struttura a directory del progetto dopo la compilazione del file aidl. 

Come possiamo vedere nella figura, l'ADT ha riconosciuto la presenza di un insieme di file AIDL e 
ha attivato il tool corrispondente per la generazione degli strumenti che ci permetteranno sia di 
implementare il servizio sia di accedervi Sebbene si tratti di un sorgente generato in modo automatico 
e quindi non modificabile dal programmatore, ne vediamo le diverse parti Notiamo innanzitutto che 
descrive un'interfaccia che si chiama come il file AIDL associato e che estende l'interfaccia 
IInterf ace del package android . os, la quale definisce la seguente unica operazione 
public abstract IBinder asBinder() 

Osservando le relative API notiamo come esse indichino la capacità di fornire un'implementazione 
di iBinder associata al servizio stesso. Questo significa che l'interfaccia chronointerface generata in 
modo automatico descrive, oltre alle operazioni che abbiamo definito, anche quella che consente di 
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ottenere l'oggetto per la loro invocazione remota. Un aspetto interessante riguarda il fatto che, 
nell'interfaccia generata, le operazioni del nostro servizio siano diventate le seguenti; 

// Attiva il Chrono se non ancora fatto 

public void start () throws android . os . RemoteException; 

// Ferma il Chrono se non ancora fatto 

public void stop() throws android. os . RemoteException; 

// Resetta il Chrono 

public void reset () throws android . os . RemoteException; 
// Setta l'orario del Chrono 

public void setTime(long time) throws android . os . RemoteException; 
// Restituisce l'orario del Chrono 

public long getTime ( ) throws android. os . RemoteException; 

dove sono stati mantenuti i commenti e a cui è stata aggiunta la gestione di un'eccezione del tipo 
RemoteException ma relativa al package android. os e quindi non al package java.rmi di Java 
standard. 

Oltre alla definizione dell'interfaccia chronoservice appena vista, il sorgente generato ne contiene 
anche un'implementazione astratta, descritta come classe interna, che lascia allo sviluppatore 
l'implementazione delle operazioni proprie del servizio integrando invece quella descritta dalla 
precedente interfaccia iinterface. Sitratta della classe chronoservice.stub, che andremo a 
specializzare per l'implementazione del nostro servizio definendo le operazioni di quest'ultimo ed 
ereditando quelle di gestione della remotizzazione. Osservando il codice generato notiamo poi la 
presenza di una ulteriore classe interna di nome Proxy che, implementando la stessa interfaccia del 
servizio, ci permetterà di accedervi lato client. Per accedere all'implementazione utilizzeremo poi il 
metodo statico 

public stati c uk . co . massimocarli . android. chronoservice . servì ce . Chrono Servi ce 
as Inter face (android . os . IBinder ob j ) 

che ci ritornerà il riferimento all'oggetto Proxy per l'invocazione delle operazioni del servizio come 
se fossero locali, nascondendoci il fatto che questo comporti della elaborazione relativa alla 
comunicazione tra processi diversi. 

Implementazione del servizio 

Senza perderci in ulteriori dettagli passiamo a quella che è l'implementazione del servizio che 
intendiamo sviluppare. Da quanto visto nel paragrafo precedente, non dovremo fare altro che creare 
un'implementazione della classe chronoservice . stub generata automaticamente dall' ADT. A tal 
proposito esistono alcune limitazioni. La prima riguarda la gestione delle eccezioni che non vengono 
propagate al client. Molto importante è il fatto che le chiamate siano sincrone e che è bene che i 
diversi client le eseguano all'interno di thread diversi da quello di gestione della UI. Un'ultima 
considerazione riguarda il fatto che le interfacce AIDL non consentono la definizione di costanti che 
dovranno eventualmente essere definite localmente. 

Nel nostro caso l'implementazione della classe astratta chronoservice.stub è stata definita 
all'interno della classe chronoserviceimpi attraverso questo codice: 

public class ChronoServicelmpl extends ChronoService . Stub { 
private static class Chrono implements Runnable { 
private static final long INTERVAL = 100L; 
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private volatile boolean mRunning; 



private Thread mThread; 

private final AtomìcLong mCurrentChronoTime; 

private long mLastMeasuredTime; 

public Chrono ( ) { 

mCurrentChronoTime = new AtomicLong ( ) ; 

} 

public void setTime ( final long newTime) { 
mCurrentChronoTime . set (newTime) ; 

} 

public void start () { 
ìf ( ! mRunning) { 

mCurrentChronoTime .set ( OL) ; 

mLastMeasuredTime = SystemClock . uptimeMillis ( ) ; 

mRunning = true; 

mThread = new Thread (this ) ; 

mThread . start ( ) ; 

} 

} 

public void stop() { 
ìf (mRunning) { 

mRunning = false; 
mThread = nuli; 

} 

} 

@Override 

public void run() { 
while (mRunning) { 

try{ Thread. sleep (INTERVAL) ; } 

catch ( InterruptedException ìe) { } 

final long now = SystemClock . uptimeMillis () ; 

mCurrentChronoTime . addAndGet (now - mLastMeasuredTime); 

mLastMeasuredTime = now; 

} 

} 

public long getTime() { 

return mCurrentChronoTime . get () ; 

} 

} 

private Chrono mChrono; 

public ChronoServicelmpl ( ) { 
mChrono = new Chrono ( ) ; 

} 

SOverride 

public void start () throws RemoteExceptìon { 
mChrono . start ( ) ; 

} 

SOverride 

public void stop() throws RemoteException { 
mChrono . stop ( ) ; 

} 

SOverride 

public void reset () throws RemoteExceptìon { 
setTime (OL) ; 

} 



SOverride 

public void setTime ( long time) throws RemoteException { 
mChrono . setTime (time) ; 

} 

@Override 

public long getTime() throws RemoteException { 
return mChrono . getTime ( ) ; 

} 

} 

Come possiamo notare, si tratta della semplice implementazione delle operazioni che abbiamo 
definito all'interno delfileAIDLe che descrivono appunto le funzioni del nostro servizio che 
descriviamo attraverso la classe di nome ChronoBoundService, che non è comunque banale per 
un'importante ragione. Supponiamo infatti di creare, come faremo successivamente, un'activity con 
due pulsanti: imo per lo start e uno per lo stop, oltre a imo per l'acquisizione del tempo corrente. In 
fase di visualizzazione dell' activity eseguiremo un bindservice ( ) ottenendo il riferimento al servizio 
che utilizzeremo per invocare il metodo start ( ) e avviare il timer. Supponiamo ora di uscire 
dall'applicazione e fare l'unbindservice ( ) . Il nostro servizio, però, non è più referenziato da alcun 
componente e viene quindi eliminato insieme al thread di gestione del cronometro che abbiamo 
descritto dalla classe interna chrono nel codice precedente. Serve allora un meccanismo che permetta 
di gestire il ciclo di vita del servizio mantenendolo vivo fino a che non è effettivamente utile. 
Implementiamo inizialmente il nostro servizio nel modo più semplice possibile: 

public class ChronoBoundService extends Service { 
private ChronoServìcelmpl mChronoImpl; 
SOverride 

public void onCreateO { 
super . onCreate ( ) ; 

mChronoImpl = new ChronoServicelmpl () ; 

} 

@Override 

public IBìnder onBind ( Intent intent) { 
return mChronoImpl; 

} 

SOverride 

public void onDestroyO { 
super . onDestroy ( ) ; 
try { 

mChronoImpl . stop ( ) ; 
} catch (RemoteException e) { 
e . printStackTrace ( ) ; 

} 

mChronoImpl = nuli; 

} 

} 

e procediamo alla creazione dell'attività di test. Vediamo come si sia semplicemente creata 
un'istanza della classe ChronoServicelmpl nel metodo onCreate ( ) ritornandola poi come risultato del 
metodo onBind ( ) . Nel metodo onDestroy ( ) , che viene chiamato quando non vi è più alcun binding al 
servizio da parte dei client, non facciamo altro che terminare il thread del cronometro mettendo il 
riferimento a nuli. 

La nostra MainActivity contiene il codice che ci consente di eseguire il binding in corrispondenza 
del metodo onstart ( ) , ottenere il riferimento al servizio e quindi rilasciarlo in corrispondenza del 
metodo onstop o . Il codice di nostro interesse è il seguente: 



422 



public class MainActivity extends Activity { 

private ServiceConnection mServiceConnection = new ServiceConnection () { 
gOverride 

public void onServiceConnected (ComponentName name, IBinder service) { 
mChronoService = ChronoService . Stub . aslnterface (service) ; 

} 

gOverride 

public void onServiceDisconnected (ComponentName name) { 
mChronoService = nuli; 

} 

}; 

private ChronoService mChronoService; 
SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentVìew (R . layout . activity_main) ; 

} 

gOverride 

protected void onStart ( ) { 
super . onStart ( ) ; 

bindService (new Intent(this, ChronoBoundService . class) , 
mServiceConnection, Context . BIND_AUTO_CREATE) ; 

} 

gOverride 

protected void onStop ( ) { 
super . onStop ( ) ; 

unbindService (mServiceConnection) ; 

} 

public void buttonPressed (final View button) { 
switch (button . getld () ) { 
case R. id . start_button : 
try { 

mChronoService . start ( ) ; 
} catch (RemoteException e) { 
e .printStackTrace () ; 

} 

break; 
case R . id . stop_button : 
try { 

mChronoService . stop ( ) ; 
} catch (RemoteException e) { 
e .printStackTrace () ; 

} 

break; 

case R. id . reset_button : 
try { 

mChronoService . reset () ; 
} catch (RemoteException e) { 
e .printStackTrace () ; 

} 

break; 
default : 
break; 

} 

} 



La modalità con cui si ottiene il riferimento al servizio è molto semplice e consiste nella creazione di 
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un'implementazione dell' interfaccia serviceconnection, che contiene i metodi di callback invocati in 
corrispondenza del bind ( ) e unbind ( ) . Nella prima di queste operazioni otteniamo il riferimento al 
nostro servizio remoto attarverso l'istruzione 

mChronoService = ChronoService . Stub . aslnterface (service) ; 

la cui implementazione è stata generata in fase di building a partire dal file AIDL di partenza. 
L'integrazione tra il ciclo di vita dell' activity e quello del servizio avviene invece nei metodi onstart ( ) 
e onstop ( ) nel seguente modo: 

SOverride 

protected void onStartO { 
super . onStart () ; 

Log . i (Conf . TAG_LOG, "Activity started"); 
bindService (new Intent (this, ChronoBoundService . class) , 
mServiceConnection , Context . BIND_AUTO_CREATE ) ; 

} 

dOverride 

protected void onStopO { 
super . onStop ( ) ; 

Log. i (Conf .TAG_LOG, "Activity stopped"); 
unbindService (mServiceConnection) ; 

} 

A questo punto invitiamo il lettore a fare la seguente prova. Dopo aver avviato l'applicazione, 
premiamo il pulsante Start e usciamo dall'applicazione stessa. Dai log si noterà qualcosa di questo 
tipo: 

Activity started 
ChornoBound onCreate 
ChornoBound onBind 

We got reference to the bound service: 

uk . co . massimocarli . andrò id . chronoservice . service . ChronoServiceImpl@4 lc398f 0 
CHRONO START INVOKED 
CHRONO STEP! 102 
CHRONO STEP! 2 02 

CHRONO STEP! 150 6 
CHRONO STEP! 160 6 
Activity stopped 
ChornoBound onDestroy 
CHRONO STOP INVOKED 
CHRONO STEP! 1707 

All'inizio si ha il log relativo all'operazione di bind seguita poi dall'avvio del thread associato al 
chrono. Quando abbiamo selezionato il pulsante Back per uscire dall'applicazione notiamo come sia 
stato eseguito l' unbind, che quindi ha portato alla distruzione del servizio di cui abbiamo avuto 
notifica attraverso l'invocazione del metodo onDestroy o. Da quanto osservato abbiamo capito che 
qualcosa non funziona, in quanto vorremmo che il cronometro continuasse a funzionare fino a che non 
premiamo il pulsante Stop. Questo ci porta a osservare che forse quello di cui abbiamo bisogno è 
qualcosa di ìbrido, ovvero un servizio di cui decidiamo noi il ciclo di vita e quindi vicino a quello che è 
un servizio Started. 

Decidiamo allora di seguire un'altra strada che prevede che i pulsanti Start, Stop e Reset 
interagiscano con il servizio attraverso degli opportuni intent inviati attraverso Ita rtService ( ) , 
mentre un'interfaccia remota ci permetterà di ricevere, attraverso callback, il valore corrente. Per 
quanto riguarda la prima parte il tutto è abbastanza semplice e automatico, soprattutto alla luce di 
quanto fatto finora. La creazione del callback richiede invece un accorgimento nuovo. È infatti una 
notifica che viene fatta dal servizio al relativo client attraverso un'interfaccia che può essere remota. 
Quello che faremo sarà la definizione di una nuova interfaccia AIDL per il metodo di callback come la 
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seguente: 

package uk . co . massimocarli . andrò id . chrono servi ce . service; 
interface ChronoCallback { 

// Invocato quando l'orario cambia 
void currentTime (String currentTime); 

} 

ma soprattutto dovremo aggiungere alla precedente interfaccia due operazioni che consentiranno al 
client di registrare e deregistrare le implementazione di ChronoCallback per la notifica del tempo. 
L'interfaccia del nostro servizio diventerà questa: 

package uk . co . massimocarli . android. chrono servi ce . service; 

import uk . co .massimocarli . android . chronoservice . service . ChronoCallback; 

interface ChronoService { 
void start ( ) ; 
void stop ( ) ; 
void reset ( ) ; 
void setTime (long time) ; 
long getTime ( ) ; 

void registerCallback (ChronoCallback callback) ; 
void unregisterCallback (ChronoCallback callback) ; 

} 

dove notiamo la presenza dei due metodi che permettono a un'implementazione di ChronoCallback 
di registrarsi come listener dell'informazione del chrono. A questo punto la classe 
chronoBoundService che implementa l'interfaccia remota dovrà implementare anche i due nuovi 
metodi e salvare il riferimento all'oggetto che poi verrà utilizzato per la notifica di callback. Abbiamo 
infatti il seguente codice: 

public class ChronoBoundService extends Service { 
private ChronoServicelmpl mChronoImpl; 
@Override 

public int onStartCommand ( Intent intent, int flags, ìnt startld) { 
if (intent == nuli) { 

return Service . START_NOT_STICKY; 

} 

final String requestedAction = intent . getAction () ; 
if (ServiceUtil.START_CHRONO_ACTION.equals (requestedAction) ) { 
try { 

mChronoImpl . start ( ) ; 
} catch (RemoteExceptìon e) { 
e .prìntStackTrace () ; 

} 

} else if (ServiceUtil . STOP_CHRONO_ACTION. equals (requestedAction) ) { 
try { 

mChronoImpl . stop ( ) ; 
} catch (RemoteException e) { 
e . pr int StackT race ( ) ; 

} 

} else if (ServiceUtil . RESET_CHRONO_ACTION . equals (requestedAction) ) { 
try { 

mChronoImpl . reset ( ) ; 
} catch (RemoteException e) { 
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e .printStackTrace () ; 

} 

} 

return super . onStartCommand ( intent, flags, start Id) ; 

} 

@Override 

public void onCreateO { 
super . onCreate ( ) ; 

mChronoImpl = new ChronoServicelmpl ( ) ; 

} 

@Override 

public IBinder onBind ( Intent intent) { 
return mChronoImpl; 

} 

SOverride 

public void onDestroyO { 
super . onDestroy ( ) ; 
try { 

mChronoImpl . stop ( ) ; 
} catch (RemoteException e) { 
e . printStackTrace ( ) ; 

} 

mChronoImpl = nuli; 

} 

} 

Rispetto al caso precedente, abbiamo implementato il metodo onStartCommand ( ) in modo da 
rispondere ad altrettante azioni che abbiamo descritto all'interno della classe di utilità s erviceUtil. 
Le modifiche maggiori sono invece state nell'implementazione dell'interfaccia remota, ovvero nella 
classe ChronoServicelmpl. Abbiamo infatti dovuto aggiungere l'implementazione delle due nuove 
operazioni di registrazione e deregjstrazione degli oggetti di callback, i quali non fanno altro che 
passare il riferimento al thread responsabile della notifica: 

@Override 

public void registerCallback (final ChronoCallback callback) 
throws RemoteException { 
mChrono . setCallback (callback) ; 

} 

@Override 

public void unregisterCallback ( final ChronoCallback callback) 
throws RemoteException { 
mChrono . setCallback (nuli) ; 

} 

A sua volta il thread di conteggio dovrà preoccuparsi della notifica del valore relativo al tempo. Il 
metodo run o della classe chrono diventa il seguente: 

SOverride 

public void run ( ) { 
while (mRunning) { 

try { Thread. sleep (INTERVAL) ; } catch ( InterruptedException ie) {} 
final long now = SystemClock . uptimeMillis ( ) ; 
mCurrentChronoTime . addAndGet (now - mLastMeasuredTime); 
mLastMeasuredTime = now; 

mCalendar . setTimelnMillis (mCurrentChronoTime . get ( ) ) ; 

final String timeAsString = DATE_FORMAT . format (mCalendar . getTime ()) ; 
if (mCallback != nuli && ! timeAsString . equals (mCurrentAsString) ) { 

mCurrentAsString = timeAsString; 

try { 

mCallback . currentTime (mCurrentAsString) ; 

} catch (RemoteException e) { 
e . printStackTrace ( ) ; 

} 

} 
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} 

} 

In questo codice abbiamo messo in evidenza l'invocazione del metodo ourrentTime O sull'oggetto 
per il callback. Dobbiamo pensare a questo oggetto come a qualcosa che viene dato al nostro 
servizio e che il servizio stesso utilizza per la notifica. Come abbiamo visto, si tratta di qualcosa che 
espone un'interfaccia remota che abbiamo descritto attraverso un documento AIDL e che quindi ha 
generato la classe di stub. Ma dove viene creato questo oggetto? La risposta sta 
nell'implementazione dell' activity, che ora è molto più complicata della precedente e contiene alcune 
modifiche molto importanti La prima di queste è relativa all'implementazione dell'interfaccia 
serviceconnection, che ora diventa questa: 

private ServiceConnection mServiceConnection = new ServiceConnection ( ) { 
SOverride 

public void onServiceConnected (ComponentName name, IBinder service) { 
mChronoService = ChronoService . Stub . aslnterface (service) ; 
try { 

mChronoService . registerCallback (mChronoCallback) ; 

} catch (RemoteException e) { 
e .printStackTrace ( ) ; 

} 

} 

SOverride 

public void onServiceDisconnected (ComponentName name) { 
try { 

mChronoService . unregisterCallback (mChronoCallback) ; 

} catch (RemoteException e) { 
e .printStackTrace ( ) ; 

} 

mChronoService = nuli; 

} 

}; 

Infatti non appena otteniamo il riferimento al servizio remoto lo dobbiamo utilizzare per la 
registrazione dell'oggetto che implementa l'interfaccia di callback. Simmetricamente, dobbiamo poi 
deregistrare lo stesso oggetto dal servizio prima di perdere il riferimento allo stesso. Per farlo 
abbiamo invocato le due opeazioni registerCallback o e unregisterCallback o definite in 
precedenza. Da notare come, essendo delle interfacce remote, si rende necessario dover gestire le 
eccezioni corrispondenti Abbiamo bisogno dell'implementazione dell'interfaccia di callback, che 
abbiamo definito attraverso la seguente dichiarazione: 

private ChronoCallback mChronoCallback = new ChronoCallback . Stub ( ) { 
@Override 

public void currentTime ( String currentTime) throws RemoteException { 
final Message timeMessage = mUpdateTimeHandler . obtainMessage (0, 

currentTime) ; 
mUpdateTimeHandler . sendMessage (timeMessage) ; 

} 

}; 

È una classe che estende il corrispondente stub generato in modo automatico in fase dibuild. 
All'interno del metodo di callback dovremo gestire la visualizzazione in una Textview che abbiamo 
aggiunto al layout insieme a un pulsante che, come vedremo dopo, consente la chisura del servizio. 
Anche in questa fase dobbiamo però fare attenzione in quanto il metodo di callback non viene 
invocato nel thread principale e quindi non può interagire con i componenti della UI. Capito il 
problema ne sappiamo già la soluzione, che consiste nella definizione di un handler che abbiamo 
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descritto nella classe updateTimeHandier. Per il momento nel metodo dicallback notiamo l'utilizzo 
dell'handler per l'invio di un messaggio che contiene la string da visualizzare all'interno del suo 
campo obj. La classe updateTimeHandier è ora alquanto familiare: 

private static class UpdateTimeHandier extends Handler { 

private WeakRef erence<MainActivity> mActivityRef ; 

public UpdateTimeHandier ( final MainActivity activity) { 

this . mActivityRef = new WeakRef erence<MainActivity> (activity) ; 

} 

SOverride 

public void handleMessage (Message msg) { 
super . handleMessage (msg) ; 

final MainActivity activity = mActivityRef . get () ; 
if (activity != nuli) { 

activity . updateTime (msg . ob j . toString ( ) ) ; 

} 

} 

} 

A parte il discorso relativo alla necessità di rendere la classe interna statica al fine di eliminare gli 
eventuali memory leak, vediamo come, in corrispondenza della ricezione del messaggio, venga 
visualizzato il valore del campo obj all'interno di ima Textview. In realtà invochiamo il metodo 
updateTime o suU'activity, il quale contiene il codice di visualizzazione. 

L'ultima considerazione sulla nostra activity riguarda F implementazione dei metodi di interazione 
con il servizio che ora viene utilizzato sia come Started sia come Bound. La prima modalità è quella 
che ci permette di avviarlo, interromperlo e resettarlo. La seconda è quella attraverso la quale 
otteniamo ilcallback al dato del cronometro da visualizzare. Il tutto è implementato in questi metodi; 

SOverride 

protected void onStartO { 
super . onStart () ; 

bindService (new Intent(this, ChronoBoundService . class) , 
mServiceConnection, Context . BIND_AUTO_CREATE) ; 

} 

SOverride 

protected void onStopO { 
super . onStop ( ) ; 

unbindService (mServiceConnection) ; 

} 

private void updateTime ( final String time) { 
mOutput . setText (time) ; 

} 

public void buttonPressed ( final View button) { 

final Intent servicelntent = new Intent (this, ChronoBoundService . class ) ; 
switch (button . getld () ) { 
case R . id . start_button : 

servicelntent . setActìon (ServìceUtil . START_CHRONO_ACTION) ; 

startService (servicelntent) ; 

break; 
case R . id . stop_button : 

servicelntent . setActìon (ServìceUtil . STOP_CHRONO_ACTION) ; 

startService (servicelntent) ; 

break; 

case R . id . reset_button : 

servicelntent . setActìon (ServìceUtil . RESET_CHRONO_ACTION) ; 
startService (servicelntent) ; 

break; 
case R . id . kill_button : 

servicelntent . setActìon (ServìceUtil . KILL_CHRONO_ACTION) ; 
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stopService (servicelntent) ; 

break; 
default : 
break; 

} 

} 

Nei metodi onstart o eonstopo esegukmo rispettivamente le operazioni di bindservice () e 
unbindService ( ) . All'interno del metodo che viene eseguito in corrispondenza della pressione dei 
diversi pulsanti nell'interfaccia invocheremo invece i metodi startservice o e stopService o . In 
particolare i pulsanti relativi alle azioni di Start, Stop e Reset portano all'invocazione del metodo 
startservice o , a differenza del pulsante di Kill che porta all'invocazione del metodo 
stopService ( ) , come evidenziato nel codice precedente. 

Non ci resta che verificarne il corretto funzionamento attraverso un semplice test che invitiamo il 
lettore a eseguire. Avviamo l'applicazione e selezioniamo il pulsante Start. Se la nostra 
implementazione è corretta dovremo vedere sul display il tempo del cronometro che avanza. 



^ ChronoService 




00:16 




Figura 9.22 il cronometro in esecuzione. 

A questo punto ripetiamo l'esperiemento fatto con l'applicazione precedente, ovvero usciamo 
premendo il pulsante Back. Attendiamo un po' e poi rientriamo osservando come effettivamente non 
solo è trascorso del tempo coerente ma anche che il cronometro continua all'aggiornamento del 
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valore visualizzato. Il servizio non viene eliminato proprio per il fatto che si tratta di un servizio 
Started che avviamo attraverso un intent. Per questo motivo il cronometro continuerà indefinitamente 
(se il sistema non decide di eliminarlo per la necessità di risorse particolari) a meno che non si prema il 
pulsante KM. Questa azione e quindi l'invio dell' intent corrispondente attraverso il metodo 
stopservice ( ) non provocano la chiusura del servizio in quanto comunque resta in piedi il riferimento 
fatto attraverso l'operazione dibindservice o . Se ora usciamo dall'applicazione attraverso la 
pressione del pulsante Back noteremo come il servizio venga effettivamente distrutto. Questo perché 
l'utilizzo come servizio Started è terminato nel momento in cui è stato eseguito il metodo 

startService ( ) e quello COme Bound nel momento dell' unbindService ( ) . 

In questo impegnativo paragrafo abbiamo visto come implementare i service nelle due modalità 
Started e Bound. Sono componenti molto importanti che è bene conoscere nel dettaglio allo scopo 
di sviluppare applicazioni sempre migliori. 

Broad cast Recei ver 

Nella precedente parte del capitolo ci siamo occupati di componenti in grado di eseguire delle 
operazioni in background. Questo avviene solitamente quando dobbiamo eseguire delle operazioni 
senza disturbare quello che è il livello di interattività di un'applicazione. In altre situazioni si ha invece 
la necessità opposta, ovvero di attivare delle operazioni, spesso di breve durata, a seguito di 
particolari eventi per lfuire delle relative informazioni Pensiamo per esempio alla ricezione di un SMS 
che presuppone la sua registrazione all'interno di un particolare repository, oppure di una telefonata le 
cui informazioni dovranno essere memorizzate nel registro delle chiamate. A tal proposito Android 
mette a disposizione un tipo di componente chiamato Broadcast Recei ver le cui caratteristiche sono 
descritte dall'omonima classe del package android. content. 

NOTA 

Possiamo pensare a questo componente come alla versione per Android del Push Registry delle 
MIDP 2.0, che permette l'attivazione di un'applicazione a seguito di un particolare evento come 
appunto la ricezione di un SMS o di una chiamata. 

Come nel caso del Push Registry, anche per i BroadcastReceiver la registrazione a un particolare 
evento, che in Android sarà descritto da un intent, potrà avvenire sia in modo dichiarativo nel file 
AndroidManifest .xml sia in modo programmatico, ovvero da codice. Nel primo caso è possibile 
utilizzare l'elemento <receiver/> associando i relativi intent filter. Nel secondo si può invece utilizzare 
il metodo 

public abstract Intent registerReceiver (BroadcastReceiver receiver, IntentFilter 
filter) 

che consente di eseguire il BroadcastReceiver nello stesso mainthread dell'applicazione 
corrispondente. Disolito la registrazione programmatica di un BroadcastReceiver si ha in 
corrispondenza del metodo onResume ( ) , mentre la deregistrazione in corrispondenza del metodo 
onPause ( ) al fine di non impegnare il sistema in gestioni inutili 

È importante sottolineare come la gestione degli intent utilizzati per le activity non sia legata in alcun 
modo a quella dei BroadcastReceiver: mentre la prima permette di passare da un' attività a un'altra a 
seguito di un'azione dell'utente, nel caso dei BroadcastReceiver l'interazione è completamente 
asincrona. 

Gli intent ricevuti da un componente di questo tipo possono essere generati da una specializzazione 
di Context attraverso uno di questi due metodi: 
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public abstract void sendBroadcast (Intent intent) 

public abstract void sendOrderedBroadcast (Intent intent, String receiverPermission) 

Nel primo caso F intent viene inviato in broadcast a tutti i componenti che si sono registrati, i quali 
lo ricevono in un ordine non prefissato. Nel nostro caso, invece, si può dare un ordine ai 
BroadcastReceiver in base a una priorità che è possibile impostare attraverso l'attributo 
andrò id :priority dei corrispondenti intent Alter. L'ambiente non garantisce un ordine particolare nei 
confronti di quei componenti con la stessa priorità. Relativamente ai vari metodi di registrazione 
notiamo come alcuni di questi prevedano un parametro relativo al particolare permesso, come 
vedremo nel capitolo corrispondente. 

Anche per un BroadcastReceiver esiste il concetto di ciclo di vita, il quale però corrisponde alla 
singola esecuzione della operazione: 

public abstract void onReceive (Context context, Intent intent) 

Questo significa che il componente sarà considerato attivo solamente durante l'esecuzione di 
questo metodo, dopodiché potrà essere eliminato dal sistema. Questo impedisce a un 
BroadcastReceiver di ottenere il riferimento a un servizio o ad aprire finestre di dialogo. 

Come esempio di utilizzo riprendiamo il nostro timer facendo in modo che venga generata una 
notifica in corrispondenza del raggiungimento di un tempo che per comodità indichiamo in 10 secondi 
(ma che potrà essere cambiato). La notifica potrebbe essere programmata dal servizio stesso, ma nel 
nostro caso facciamo in modo che venga generato un intent di broadcast, che viene appunto raccolto 
da un BroadcastReceiver il cuiunico scopo è quello di lanciare la visualizzazione della notifica nel 
modo che abbiamo visto nei paragrafi precedenti 

NOTA 

Un'alternativa che lasciamo al lettore come esercizio potrebbe essere quella di generare un intent di 
broadcast in occasione di ogni notifica da parte del server. In questo caso il BroadcastReceiver 
lancerebbe l'invio di notifiche in update come abbiamo imparato a fare nei paragrafi precedenti. 

Il primo passo da fare consiste nella definizione delle costanti per l'azione dell' intent che lanceremo 
in broadcast. Questo consiste semplicemente nella definizione di questa costante nella classe 

ServiceUtii: 

public static final String UPDATE_TIME_BROACAST_ACTION = 

"chronoservìce . servìce . action . UP DATE_T I ME_BROACAS T_AC T I ON " ; 

Insieme all' intent di broadcast vogliamo inviare, come extra, l' informazione relativa al tempo 
passato, per cui definiamo anche la seguente costante: 

public static final String TIME_EXTRA ="chronoservice . service . extra . TIME_EXTRA" ; 

Anche la modifica nel servizio diventa banale e precisamente consiste nell' aggiungere un test per 
l'invio della notifica e un controllo che questo avvenga una volta sola. Abbiamo quindi aggiunto queste 
righe di codice al tempo del metodo run ( ) della classe Chrono: 

if ( JmNotif icationFired && mCurrentChronoTime . get ( ) > NOTIFICAI ION_TIMEOUT) { 
final Intent broadcast Intent = 

new Intent (ServiceUtii . UPDATE_TIME_BROACAST_ACTION) ; 
broadcast Intent . putExtra (ServiceUtii . TIME_EXTRA, timeAsString) ; 
mContext . sendBroadcast (broadcast Intent) ; 
mNotìf icationFired = true; 

} 

dove la costante notification_timeout indica il tempo per la visualizzazione della notifica. Per 
l'utilizzo del metodo sendBroadcast o abbiamo avuto il bisogno di ottenere il riferimento al Context 
direttamente dall'oggetto s ervice. 

NOTA 

431 



Da notare come un intent di tipo broadcast non abbia nulla di diverso da un normale intent se non 
che verrà utilizzato da oggetti di tipo BroadcastReceiver invece che Service 0 Activity. 

Il passo successivo consiste nella definizione dell'implementazione di BroadcastReceiver, che è 
descritta dalla classe TimeBroadcastReceiver, il cui codice è molto semplice: 

public class TimeBroadcastReceiver extends BroadcastReceiver { 
private static final int TIME_NOTIFICATION_ID = 1000; 
@Override 

public void onReceive (Context context, Intent intent) { 

final String timelnfo = intent . getStrìngExtra ( ServiceUtìl . TIME_EXTRA) ; 
final String contentText = context . getResources ( ) 

. getString (R. string . notif ication_label , timelnfo) ; 
final String contentTitle = context . getResources ( ) 

. getString (R . string . notif ication_tit le) ; 
Notif ication notif ication = new Notif icatìonCompat .Builder (context) 

. setSmallIcon (R. drawable . ic_launcher) . setContentText (contentText) 

. setAutoCancel (true) 

. setContentTitle (contentTitle) .build ( ) ; 
final Notif icationManager notif icationManager = (Notif icationManager) 

context .getSystemService (Context . NOTIFICATION_SERVICE) ; 
notif icationManager . notif y (TIME_NOTIFICATION_ID, notif ication) ; 

} 

} 

Si tratta semplicemente di creare una classe che estende BroadcastReceiver fornendo 
l'implementazione del metodo onReceive ( ) che prevede, tra i parametri in input, anche l'intent di 
broadcast da cui abbiamo estratto l'informazione relativa al tempo che abbiamo poi utilizzato, a suo 
volta, per il messaggio della notifica. 

L'ultimo passo consiste nella dichiarazione del componente all'interno del file di configurazione 
AndroidManifest.xmi attraverso questa definizione: 

<receiver android: name=" . receiver . TimeBroadcastReceiver" 
android : exported=" false" > 
<intent-f ìlter> 

<action android: name=" . . . . UPDATE_TIME_BROACAST_ACTION" /> 
<category android: name="android. intent . category . DEFAULT" /> 
</intent-filter> 
</receiver> 

Qui abbiamo abbreviato il nome dell'action, che dovrà invece corrispondere a quella definita nella 
classe s erviceUtil. 

Quello realizzato è un esempio di BroadcastReceiver che si registra a un particolare intent di 
broadcast in modo esplicito all'interno del documento AndroidManif est . xml. Ma cosa succede se 
invece l'applicazione è in esecuzione e volessimo semplicemente mostrare un messaggio all'utente? In 
quel caso bisognerà fare in modo che l'activity si registri come listener dell'evento di broadcast 
disabilitando invece la notifica. È un caso abbastanza comune che abbiamo implementato nella nostra 
attività MaìnActivìty creando una variabile del tipo del BroadcastReceiver come segue: 

private BroadcastReceiver mTimeReceiver = new BroadcastReceiver () { 
@Override 

public void onReceive (Context context, Intent intent) { 

final String timelnfo = intent . getStringExtra ( ServiceUtil . TIME_EXTRA) ; 
Toast .makeText (getApplicationContext () , timelnfo, 
Toast .LENGTH_SHORT) . show ( ) ; 

} 

}; 

L'implementazione è molto semplice: visualizza un messaggio attraverso un Toast. Il passo 
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successivo consiste nel registrare ilBroadcastReceiver in corrispondenza del metodo onstart o e 
quindi deregistrarlo in corrispodenza del metodo onstop ( ) . Per tarlo abbiamo bisogno di un'istanza 
della classe intentFiiter, che descrive appunto la regola di attivazione. I nostri due metodi di 
callback diventano i seguenti: 

SOverride 

protected void onStartO { 
super . onStart () ; 

final IntentFilter broadcastlntentFilter = 

new IntentFilter (ServiceUtil .UPDATE_TIME_BROACAST_ACTION) ; 
registerReceiver (mTimeReceiver, broadcastlntentFilter) ; 

bindService (new Intent (this, ChronoBoundService . class) , 
mServiceConnection, Context . BIND_AUTO_CREATE) ; 

} 

SOverride 

protected void onStopO { 
super . onStop ( ) ; 

unregisterReceiver (mTimeReceiver) ; 

unbindService (mServiceConnection) ; 

} 

dove abbiamo messo in evidenza il codice di interesse. Se l'applicazione è in esecuzione al 
momento dell'invio dell' intent di broadcast dovremmo vedere sia la notifica sia la visualizzazione del 
messaggio di Toast. Per completare il tutto dobbiamo disabilitare ilBroadcastReceiver definito 
nell' AndroidManif est . xml HI corrispondenza del metodo onstart ( ) per poi riabilitarlo in 
corrispondenza del metodo onstop ( ) . Abbiamo così aggiunto le istruzioni evidenziate nel seguente 
codice: 

SOverride 

protected void onStartO { 
super . onStart () ; 

final IntentFilter broadcastlntentFilter = 

new IntentFilter (ServiceUtil . UPDATE_TIME_BROACAST_ACTION) ; 
registerReceiver (mTimeReceiver , broadcastlntentFilter) ; 
ComponentName component=new ComponentName (this, 

TimeBroadcastReceiver . class) ; 
getPackageManager ( ) . setComponentEnabledSetting (component , 

PackageManager . COMPONENT_ENABLED_STATE_DISABLED , 

PackageManager . DONT_KILL_APP ) ; 
bindService (new Intent (this, ChronoBoundService . class) , 

mServiceConnection, Context . BIND_AUTO_CREATE) ; 

} 

SOverride 

protected void onStopO { 
super . onStop ( ) ; 

ComponentName component =new ComponentName (this, 

TimeBroadcastReceiver. class) ; 
getPackageManager ( ) . setComponentEnabledSetting (component , 

PackageManager . COMPONENT_ENABLED_STATE_ENABLED , 

PackageManager . DONT_KILL_APP ) ; 
unregisterReceiver (mTimeReceiver) ; 
unbindService (mServiceConnection) ; 

} 

Abbiamo utilizzato un oggetto di tipo ComponentName per tare riferimento al nostro 
TimeBroadcastReceiver per poi disabilitarlo, e successivamente riabilitarlo, attraverso il metodo 
setComponentEnabledSetting ( ) delpac kageManager, che ricordiamo essere il responsabile del ciclo 
di vita delle applicazioni 

Lasciamo al lettore la verifica del fatto che effettivamente il nostro obiettivo è stato raggiunto. 
Quando l'applicazione è in esecuzione si ha la visualizzazione del Toast, mentre se l'applicazione non 
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è attiva si ha la generazione della notifica. 



Accesso asincrono ai dati con i loader 

Come abbiamo accennato diverse volte anche nei capitoli precedenti, il nostro obiettivo è quello di 
realizzare applicazioni che rispondano nel miglior modo possibile alle azioni dell'utente. Si tratta di 
quella che va sotto il nome di responsiveness. I primi strumenti a disposizione degli sviluppatori non 
permettevano, almeno fino alla versione 3.0 della piattaforma, di raggiungere grandi risultati a causa di 
una forte interazione con il thread principale dell'applicazione. Un caso tipico è quello relativo 
all'accesso ai dati attraverso il contentResoiver. Il risultato di queste operazioni, spesso eseguite 
all'interno dei metodi di callback onstart ( ) e onResume ( ) , sappiamo essere un cursor che poi è 
necessario agganciare a quello che è il ciclo di vita del componente che le contiene, ovvero activity o 
fragment. In realtà le API di Andro id ci davano l'opportunità di eseguire il tutto in modo trasparente 
attraverso l'utilizzo di due metodi che ora sono però deprecati. Invocando il metodo 

public void startManagingCursor (Cursor c) 

dopo aver ottenuto il riferimento al cursor delegavamo al sistema il fatto di liberare alcune delle 
risorse utilizzate attraverso l'invocazione del metodo deact ivate o in corrispondenza del metodo 
onstop ( ) , e quindi chiuderlo attraverso il metodo dose ( ) in corrispondenza del metodo onDestroy ( ) 
dell' activity o fragment. Se poi lo scenario era quello di una rotazione del dispositivo, il sistema si 
preoccupava di eseguire nuovamente la query e poi ripopolare il cur sor con nuovi dati II secondo 
metodo è invece quello della classe contentResoiver e precisamente 

public final Cursor managedQuery (Uri uri, Stringi] projection, 

String selection, Stringi] selectionArgs , String sortOrder) 

il quale ci consente, allo stesso tempo, di eseguire una query e di invocare il metodo precedente 
per legare i cursor al ciclo di vita del componente contenitore. Come detto lo svantaggio principale 
nel' utilizzo di questi due metodi consisteva nella necessità di eseguire le query nel thread principale, 
fatto che causava spesso errori di tipo ANR (Application Not Responding). Inoltre il Cursor ttl 
qualche modo "gestito" non era abbastanza intelligente da memorizzare i dati nel caso di variazioni 
nele configurazioni (come nel caso della rotazione), per cui anche 1 numero di volte in cui le query 
venivano eseguite non era ottimizzato. 

Il lettore potrà sicuramente osservare (a ragione) come questi siano dei metodi che abbiamo 
utilizzato nella classe ContentLocalDataFragment per la visualizzazione dele informazioni relative ai 
dati locai contenute nel content provider. Riprendendo infatti 1 metodo onStart ( ) notiamo la 
presenza del metodo hcrirninato e non solo: 

SSuppressWarnings ( "deprecation" ) 
SOverride 

public void onStartt) { 
super . onStart () ; 

mCursor = getActivity () . getContentResolver () 

. query (UghoDB . HoroVote . CONTENT_URI , nuli, nuli, nuli, nuli) ; 

getActivity () . startManagingCursor (mCursor) ; 

mAdapter = new SimpleCursorAdapter (getActivity () , 
R. layout . custom_list_item, mCursor, FROM, TO) ; 

mAdapter . set ViewBinder (new SimpleCursorAdapter .ViewBinder ( ) { 
@Override 

public boolean setViewValue (View view, Cursor cursor, int i) { 
final Textview outputTextView = (TextView) view; 
final LocalDataModel model = LocalDataModel . fromCursor (cursor) ; 

/ / Implementazione . . . 
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return true; 

} 

}) ; 

setListAdapter (mAdapter) ; 

} 

Oltre al metodo startManagingeursor ( ) abbiamo anche utilizzato il seguente costruttore della 

classe SimpleCursorAdapter: 

public SimpleCursorAdapter (Context context, int layout, Cursor c, 

Stringi] from, int [ ] to) 

che è deprecato in quanto la sua implementazione nasconde la creazione di quello che si chiama 
contentobserver, che riceve le notifìche relative alla variazione dei dati eseguendo un requery ( ) ogni 
volta che questo avviene. Essendo un'operazione che viene eseguita nel thread principale, si capisce 
come questa possa influire sulle prestazioni di un'applicazione. Il costruttore consigliato è il seguente 

public SimpleCursorAdapter (Context context, int layout, Cursor c, 

Stringi] from, int [ ] to, int flags) 

tacendo attenzione di passare 0 come valore dell'ultimo parametro, il quale permette di eliminare il 
problema. 

Da quanto esposto si capisce come nasca l'esigenza di avere degli strumenti che consentano di 
eseguire delle query in modo asicrono in modo da condizionare il meno possibile il thread principale e 
quindi la reattività delle nostre applicazioni La soluzione è stata aggiunta dalla versione 3.0 della 
piattaforma e si chiama loader. Sostanzialmente è un oggetto che permette di assolvere a due 
importanti compiti; 

• eseguire delle query in modalità asincrona; 

• aggiornare le informazioni nel caso in cui queste cambino. 

Analogamente a quanto avviene con altri tipi di componenti della piattaforma, anche per i loader 
esiste una classe che ne consente la gestione che si chiama Loade rManager. A ogni activity o fragment 
il sistema assegna un particolare LoaderManager, che gestisce il ciclo di vita di uno o più loader. 
Sebbene qualche volta si debbano, come vedremo, invocare su di esso alcune operazioni in modo 
esplicito, ciascun LoaderManager è collegato al ciclo di vita del componente corrispondente in modo 
da garantire un efficiente gestione dei relativi loader. Quali dati un loader dovrà gestire non saranno 
responsabilità del LoaderManager, che si preoccuperà solamente di eseguire lo start, lo stop e il reset 
di un loader oltre che gestirne lo stato in caso di modifiche nelle configurazioni, come può succedere 
nel caso di una rotazione del dispositivo. Capiamo come questo meccanismo sia alternativo a quello 
dei cursori "gestiti" descritto in precedenza con però diversi vantaggi II primo consiste appunto nel 
fatto che il caricamento delle informazioni avviene, per la natura stessa di un loader, in un thread 
separato che quindi non influisce sul lavoro relativo al thread della UI. Come vedremo, un Loader<D> 
è una classe generica, per cui rappresenta un meccanismo che non è vincolato al caso dei cursor ma 
che può essere esteso alla creazione e all'aggiornamento di un qualunque oggetto. Infine abbiamo già 
detto che si tratta di un meccanismo che incapsula la logica di gestione dello stato nel caso delle 
rotazioni Ma come si utilizzano? 

A tal proposito abbiamo creato la classe Loade rLocalDataFragment, che sostituirà la classe 
contentLocaiDataFragment contenente codice deprecato. Da quanto visto, capiamo come il 
LoaderManager necessiti di alcune informazioni relativamente al loader che vogliamo implementare; 
per fornirle serve implementare una particolare interfaccia che si chiama 
LoaderManager. LoaderCaiibacks<D> e che prevede la definizione delle tre seguenti operazioni: 
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public Loader<D> onCreateLoader (int id, Bundle args) 



public void onLoadFinished (Loader<D> loader, D data) 
public void onLoaderReset (Loader<D> loader) 

Il metodo onCreateLoader ( ) permette di costruire e ritornare l'implementazione del Loader<D> per 
l'oggetto di tipo d. Può capitare, anche se abbastanza raramente, di avere l'esigenza di creare qualche 
implementazione particolare di loader che nella maggiore parte dei casi fa riferimento a oggetti di tipo 
cursor. Per questo motivo l'SDK ci olire una classe che si chiama cursorLoader e che è 
effettivamente un'implementazione di Loader<cursor>. 

Una volta che il LoaderManager ottiene la particolare implementazione di loader, si preoccuperà di 
fare in modo che le informazioni vengano caricate in modo asincrono dandone poi notifica attraverso 
l'invocazione del secondo metodo, ovvero onLoadFinished o. All'interno di questo metodo di 
callback andremo a mettere la logica di aggiornamento della UI. 

Infine, il metodo onLoaderReset o viene invocato nel momento in cui il LoaderManager decide di 
eliminare tutti i dati contenuti nel loader corrispondente. Per il client questo rappresenta un punto in 
cui eventualmente provvedere all'eliminazione delle risorse eventualmente allocate all'interno del client 
stesso. 

Nella nostra applicazione abbiamo realizzato la seguente implementazione dell'interfaccia di 
callback: 

private LoaderManager . LoaderCallbacks<Cursor> mLoaderCallbacks 

= new LoaderManager . LoaderCallbacks<Cursor> ( ) { 

SOverride 

public Loader<Cursor> onCreateLoader (int i, Bundle bundle) { 

return new CursorLoader (getActivity () , UghoDB . HoroVote . CONTENT_URI , 
nuli, nuli, nuli, nuli) ; 

} 

SOverride 

public void onLoadFinished (Loader<Cursor> cursorLoader , Cursor cursor) { 
switch (cursorLoader .getld() ) { 
case LOADER_ID : 

mAdapter . swapCursor (cursor) ; 
break; 

} 

} 

SOverride 

public void onLoaderReset (Loader<Cursor> cursorLoader) { 
mAdapter . swapCursor (nuli) ; 

} 

}; 

Notiamo come in effetti si tratti di un'implementazione banale e il più delle volte quasi automatica. 

Nel metodo onCreateLoader O abbiamo Semplicemente Creato un Oggetto di tipo CursorLoader 

passando i parametri necessari all'esecuzione della query. Nel metodo onLoadFinished o non 
facciamo altro che aggiornare il cursore nell'adapter. Nel caso di reset, infine, il cursore verrà passato 
come nuli, lo stesso valore che ha all'inizio, come possiamo vedere nell'implementazione del metodo 
onstart ( ) , nel quale abbiamo omesso l'implementazione del viewBìnder per motivi di spazio: 

@Override 

public void onStartO { 
super . onStart () ; 

mAdapter = new SimpleCursorAdapter (getActivity () , 

R. layout . custom_list_item, nuli, FROM, TO, 0); 

mAdapter . setVìewBinder (new SimpleCursorAdapter .ViewBinder ( ) { 
// Come prima 
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}) ; 

setListAdapter (mAdapter) ; 

getLoaderManager () . initLoader (LOADER ID, nuli, mLoaderCallbacks) ; 

} 

Qui dobbiamo fare alcune considerazioni molto importanti. La prima riguarda il fatto che il 
costruttore utilizzato sia quello con l'ultimo parametro intero a o, ovvero quello che non contiene i 
famosi contentobserver che scatenano operazioni di requery ( ) nel thread principale nel caso di 
modifiche nella base dati Attenzione però: la classe limpieCursorAdapter utilizzata non è quella 
dell'SDK standard ma quella della Compatibility Library. Nella piattaforma standard quel 
costruttore non è infatti disponibile se non dalla versione relativa alle API Level 1 1 . 

Vediamo poi come il cursore non sia stato definito in questo metodo e come infatti il valore 
corrispondente nel costruttore del simpieCursorAdapter sia nuli. Infine abbiamo l'inizializzazione del 
loader specificando un identificatore e il riferimento all'implementazione dell'interfaccia dicallback. 
L'identificatore consente al LoaderManager di riutilizzare eventualmente un loader già creato invece 
che istanziarne uno nuovo. Il secondo parametro corrisponde a un Bundie opzionale che nel nostro 

CaSO è nuli. 

Lasciamo al lettore la verifica di come il risultato sia dal punto di vista funzionale lo stesso, anche se 
è già percepibile il fatto che il reperimento dei dati avviene in modo asincrono. 

Conclusioni 

Siamo giunti al termine di questo capitolo, che è forse il più impegnativo di tutto il libro, poiché 
tratta argomenti non banali che però assumono una grande importanza nella realizzazione di 
applicazioni Andro id. Siamo partiti da alcuni concetti generali relativi alla gestione dei thread in Java. 
Abbiamo visto che cosa sono gli handler e i looper, che ci hanno permesso di implementare un 
pattern che si chiama pipeline thread. Si tratta sostanzialmente della trasformazione di un thread in un 
sistema che comprende una coda di messaggi, e di un handler per l'elaborazione degli stessi 
Abbiamo visto come creare un handler associato al thread UI e come, invece, crearne imo relativo a 
un thread generico grazie all'utilizzo di un looper. Questo ci ha permesso di affrontare l'importanza 
dell'interazione con il thread principale dell'applicazione, da cui la definizione di un AsyncTask. Dopo 
ima trattazione approfondita di come vengano gestite le notifiche siamo passati ai concetti fondamentai 
di service Start ed e service Bound. Per entrambi i tipi di componenti abbiamo realizzato degli 
esempi Abbiamo poi descritto nel dettaglio che cosa sono i BroadcastReceiver, per concludere con 
i loader. Terminato questo capitolo il lettore dovrebbe aver acquisito la conoscenza sui principali 
meccanismi di interazione asincrona tra i componenti e dovrebbe essere in grado di realizzare 
applicazioni con un elevato grado di responsiveness. 
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Capitolo 10 



Sicurezza e networking 



In questo capitolo affronteremo due argomenti che sono collegati tra loro e che assumono 
moltissima importanza in ogni applicazione Andro id. Ci occuperemo infatti di sicurezza e di 
networking. Come sappiamo i dispositivi mobili contengono moltissime informazioni personali che 
sarebbe bene proteggere il più possibile da applicazioni che ne vorrebbero fare un uso sbagliato. 
Pensiamo per esempio a un'applicazione che legge i nostri contatti e inizia a inviare mail di spamming 
o sconvenienti a tutti i nostri amici, clienti o comunque conoscenti Pensiamo a un'altra applicazione 
che invece vuole sapere in ogni momento dove ci troviamo. Per questo motivo da subito l'architettura 
di Andro id ha messo la sicurezza tra i primissimi posti. 

La seconda parte del capitolo è invece dedicata agli strumenti che la piattaforma ci fornisce per 
accedere alla Rete. Sono ormai pochissime infatti le applicazioni che non si connettono ad alcuna 
base dati remota, visto anche il successo delle architetture cloud di questi ultimi anni Si tratta di due 
argomenti correlati in quanto, come vedremo, le applicazioni che necessitano di una connessione alla 
Rete dovranno richiedere il permesso esplicitamente. Concluderemo poi il capitolo trattando le basidi 
un framework, di nome Volley, che è stato presentato all'ultima Google IO (quella del 20 13) e che 
permette di invocare delle richieste HTTP in modo relativamente semplice e affidabile. 

Android Security Model 

Come accennato, l'architettura di Android e stata da subito studiata in modo tale da permettere la 
realizzazione di applicazioni sicure attraverso l'adozione di meccanismi che permettano di: 

• proteggere i dati sensibili degli utenti tra cui principalmente e-mail e contatti 

• proteggere le risorse di sistema; 

• proteggere le applicazioni da altre potenzialmente dannose. 

Questo obiettivo può essere raggiunto agendo su vari livelli di astrazione tra cui: 

• meccanismi presenti nel kernel Linux; 

• tutte le applicazioni devono essere eseguite all'interno di una propria sandbox; 

• adozione di meccanismi di IPC (Inter Process Communication) sicuri 

• firma delle applicazioni attraverso certificato; 

• utilizzo di un meccanismo basato sull'uso dei permessi. 

Inoltre l'architettura Android che abbiamo descritto nella Figura 3.1 si basa sull'assunzione che 
ciascun livello utilizzi servizi del livello sottostante in modo sicuro. A eccezione di alcune applicazioni 
che vengono necessariamente eseguite con l'utente diroot, tutte le altre vengono eseguite all'interno 
di un proprio processo Linux e della propria sandbox. Android utilizza dei meccanismi di sicurezza a 
livello di sistema che si basano su quelli di Linux consentendo la comunicazione tra processi diversi 
attraverso meccanismi di IPC. Si tratta di meccanismi di basso livello che vincolano le applicazioni 
all'interno di un proprio sandbox anche nel caso in cui queste utilizzassero codice in C++ che viene 
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definito un linguaggio nativo. La decisione di affidarsi al kernel Linux è dovuta proprio a motivazioni 
legate alla sicurezza. Linux è infatti un sistema operativo con innumerevoli installazioni anche in 
ambienti in cui la sicurezza rappresenta un aspetto fondamentale e ha quindi raggiunto una maturità 
tale da fornire elevate garanzie in tal senso. Nello specifico il kernel Linux fornisce ad Android le 
seguenti feature: 

• un modello di permessi basato sul singolo utente; 

• un alto grado di isolamento tra i vari processi; 

• un meccanismo estensibile e personalizzabile di IPC; 

• la possibilità di rimuovere parti potenzialmente dannose del kernel. 

A ciascuna applicazione viene assegnato un utente, per cui Android si può considerare come un 
vero e proprio sistema multiutente per il quale è fondamentale che: 

• l'utente A non possa accedere ai file dell'utente B; 

• l'utente A non possa consumare la memoria assegnata all'utente B; 

• l'utente A non possa togliere CPU all'utente B; 

• l'utente A non possa togliere risorse (Bluetooth, telefono e così via) all'utente B. 

Sebbene le applicazioni possano comunicare tra loro attraverso i meccanismi precedenti 
caratteristici dell'architettura, il kernel Linux assicura che questo possa avvenire in modo non 
dannoso. Le risorse assegnate a un utente (applicazione) vengono quindi protette a livello di sistema, il 
quale assegna, a ciascuna di esse, unUID (user ID) e ne permette l'esecuzione all'interno di un 
processo distinto. È un meccanismo diverso da quello che si ha in un normale sistema Linux, dove 
tutte le applicazioni condividono gli stessi permessi dell'utente che le esegue. L'esecuzione di 
un'applicazione in un singolo processo associato a un utente consente di limitare l'accesso alle risorse 
delle altre applicazioni oltre che a quelle di sistema. Come detto, si tratta di un meccanismo a livello di 
kernel che permette di applicare le stesse restrizioni anche al codice nativo. A queste regole 
sottostanno anche tutti i moduli di livello superiore e quindi il runtime, le librerie e i componenti 
principali presenti in ogni dispositivo Android. In altri ambienti gli errori, o eccezioni, vengono spesso 
utilizzati come meccanismi per rompere i vincoli di sicurezza. Nell'ambiente Android questo non 
succede in quanto gli stessi errori vengono mantenuti all'interno della sandbox e non vanno a 
influenzare il comportamento, o le risorse, assegnati alle altre applicazioni 

Un livello totale di sicurezza non esiste. Un dispositivo creato ad hoc potrebbe mettere a 
disposizione un'implementazione del kernel in grado di permettere la violazione della sandbox. Si 
tratterebbe comunque di un'implementazione diversa del kernel installato in dispositivi particolari. A 
tale proposito una possibile modalità di violazione dell'ambiente potrebbe essere quella relativa 
all'installazione di applicazioni che si attivano al boot del sistema e vengono eseguite insieme alle 
applicazioni del sistema stesso con utente root. Per evitare questo problema, Android prevede quella 
che si chiama system partition e che non è altro che un file system accessibile solamente in lettura 
che contiene le librerie di sistema, il runtime, ilframework e le applicazioni principali di sistema. Se 
l'utente avvia il dispositivo in modalità Safe, questo metterà a disposizione solamente le applicazioni 
installate nella system partition. Si tratta, come detto, di una memoria in sola lettura, che può essere 
modificata esclusivamente in fase di creazione dell'immagine dell'ambiente nel dispositivo e poi essere 
seguita da una scrittura di tale immagine. Altra conseguenza dell'utilizzo del kernel di Linux e 
dell'associazione di un utente diverso a ciascuna applicazione è che si può applicare lo stesso 
meccanismo di protezione proprio dei file Linux. A meno che uno sviluppatore non esegua in modo 
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esplicito una differente configurazione, ciascun file e accessibile solamente all'applicazione che lo ha 
creato. A questa protezione, dalla versione 3.0 della piattaforma, e possibile fornire anche un sistema 
di criptazione. In particolare il file system può essere criptato utilizzando il sistema dmcrypt di Linux 
AES128 (Advanced Encryption Standard) conCBC (Cipher Block Chaining) e ESSIV:SHA256 
(Encrypted Salt-Sector Initialization Vector). La chiave di criptazione e protetta daunAES128 ed 
è ottenuta dalla password dell'utente, e previene l'accesso ai dati se non attraverso tale credenziale. 
Per impedire poi che tale password venga ottenuta attraverso metodi sistematici di guessing attack 
(rainbow tables o brute force), la password e combinata con un SALT casuale e modificato con un 
hash SHA1 che utilizza l'algoritmo standard PBKDF2. Come resistenza a meccanismi di guessing 
attack Android impone delle regole relative alla complessità della password, che dovrà essere 
impostata da un arnministratore del dispositivo. 

Come sottolineato in precedenza, ciascuna applicazione viene eseguita all'interno di un proprio 
processo associato a un particolare utente. Alcune applicazioni hanno la necessità di interagire in 
modo approfondito con il sistema e a queste viene associato l'utente di root, il quale non ha alcuna 
limitazione. Alcuni dispositivi vengono modificati in modo da poter assumere i diritti di root e accedere 
alle funzionalità nella loro totalità. In questo caso Android non fornisce alcun metodo di protezione. 

Sicurezza a livello applicativo 

Un'applicazione Android viene solitamente scritta in Java ma può essere scritta anche in codice 
nativo, ovvero tipicamente in C++. Come abbiamo visto, il codice Java viene compilato con il 
normale compilatore fornito con il JDK (Java Development Kit), il quale genera ilbytecode 
contenuto all'interno di file con estensione .class. Oltre al codice, un'applicazione Android, dispone 
di una serie di risorse le quali vengono ottimizzate e compresse all'interno di un file intermedio con 
estensione _ap. Nella fase di building dell'applicazione, ilbytecode Java viene trasformato in 
bytecode Dalvik, ovvero la virtual machine ottimizzata per l'esecuzione di applicazioni in ambito 
mobile utilizzata da Google. I vari file con estensione . class vengono trasformati in un unico file con 
estensione . apx, che viene quindi compattato, insieme al file _ap delle risorse, all'interno di un unico 
file con estensione . apx che rappresenta la vera e propria applicazione Android. Come abbiamo visto 
nei capitoli precedenti, i principali componenti di un'applicazione Android sono i seguenti: 

• file di Configurazione AndroidManif est . xml; 

• activity; 

• service; 

• BroadcastReceiver; 

• ContentProvider. 

Di default una qualunque applicazione Android può accedere a un insieme limitato di risorse. 
L'accesso ad altre risorse può infatti avere, volutamente oppure no, ripercussioni sul normale 
funzionamento del dispositivo dal punto divista dell'interazione con l'utente, dell'accesso ai dati, 
dell'utilizzo della rete o di altri servizi costosi. La protezione verso questo insieme di funzionalità 
avviene con diverse modalità. La prima e semplicemente l'assenza diAPI per poterle gestire. Un 
esempio e quello relativo alla gestione delle informazioni relative alla SIM. Un'altra modalità di 
protezione e quella relativa alla sandbox descritta in precedenza, secondo la quale si può accedere ad 
alcune funzionalità solamente da applicazioni associate a particolari utenti II meccanismo comunque 
più usato per regolare l'accesso alle risorse sensibili e quello dei permessi (permission). Si sta 
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parlando, per esempio, dell'utilizzo diAPI per 

• gestione della videocamera; 

• localizzazione (GPS); 

• connessioni Bluetooth; 

• utilizzo del telefono; 

• invio e ricezione di SMS/MMS; 

• connessione dati via HTTP o altri protocolli di rete. 

Si tratta di risorse accessibili solamente attraverso il sistema operativo. Un'applicazione che intende 
utilizzare queste risorse dovrà dichiararlo esplicitamente nel proprio indroidManifest .xml. Sono 
informazioni che il sistema usa in fase di installazione dell'applicazione. In tale occasione, il sistema 
presenterà all'utente un report con tutte quelle che sono le funzionalità a cui l'applicazione stessa 
intende accedere. La responsabilità a questo punto passa all'utente, il quale, acconsentendo, 
permetterà all'applicazione di eseguire, anche senza alcuna successiva conferma, le operazioni 
sensibili. Se l'utente decide di non acconsentire, l'applicazione non verrà installata. È importante 
sottolineare come le funzionalità debbano essere accettate o rifiutate nella loro globalità e non esista 
un meccanismo che permetta di accettarne o negarne alcune prese singolarmente. In caso di 
installazione si tratta di grant che valgono fino alla eventuale disinstallazione. L'utente può comunque 
verificare i permessi associati a ciascuna applicazione nella corrispondente schermata delle 
impostazioni del dispositivo. Nel caso in cui l'installazione dell'applicazione avvenisse con altri sistemi, 
come per esempio il comando adb, l'accesso a funzionalità per le quali non e stato dato esplicito 
consenso da parte dell'utente porta a una security exception che ne impedisce l'utilizzo. 

Gestione dei permessi 

Come accennato in precedenza, una qualunque applicazione Android può accedere di default a un 
insieme limitato di funzionalità. Per accedere ad altre funzionalità che possono avere ripercussioni sia 
dal punto divista dell'accesso ai dati sia dello sfruttamento delle risorse, necessita di un permesso, 
che deve essere definito in modo esplicito all'interno del corrispondente AndroidManifest.xmi. Per 
esempio, per l'utilizzo di funzionalità relative alla gestione degli SMS occorre la seguente definizione: 

<manif est xmlns : android="http : / / schema s . android . com/apk/ re s /android" 
package="com . android . app .myapp" > 
<uses-permission android : name= " android . permission . RECEIVE_SMS " /> 

</manif est> 

L'installazione dell'applicazione che fa richiesta di alcuni permessi avviene su esplicita richiesta 
all'utente oppure attraverso l'utilizzo del certificato usato per la firma dell'applicazione stessa. È 
importante sottolineare che, una volta installata, un'applicazione non farà più richiesta all'utente del 
consenso. L'accesso a funzioni per le quali non e stato fornito il consenso porta spesso a delle 
security exception In alcuni casi il permesso viene utilizzato per decidere se un particolare intent 
debba o meno essere inviato a un certo BroadcastReceiver ma, in caso contrario, non porta alla 
generazione di alcun tipo di errore; qui viene usato come metodo di ulteriore filtro. L'utilizzo dei 
permessi per la selezione delle funzionalità accessibili da parte di una particolare applicazione può 
avvenire in diversi punti: 

• durante l'accesso a una funzionalità di sistema; 

• all'avvio di un'activity per certificare se la stessa possa essere avviata o meno dall'applicazione 
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chiamante; 

• durante l'invio e la ricezione di un intent in broadcast per controllare chi può inviare e chi 
invece ricevere; 

• durante l'accesso alle informazioni contenute all'interno di un content provider; 

• durate l'avvio o il binding di un servizio. 

Le API della piattaforma dispongono di una serie di permessi predefiniti, ma lo stesso meccanismo 
può essere utilizzato da parte di una qualunque altra applicazione per proteggere le proprie 
funzionalità. Il primo passo consiste nella definizione, nefl'AndroidManifest.xmi, dei permessi 
personalizzati attraverso l'elemento < P ermission/>: 

<manif est xmlns : android="http : //schemas . android . com/ apk/res/android" 
package="com.me . app .myapp" > 
<permission android : name=" com . me . app .myapp .permission . DEADLY_ACTIVITY" 
android : labe 1= " @st ring /permlab_deadlyActivity " 
android: descript ion=" @string/permdesc_deadlyActivity" 
android : permissionGroup=" android . permission-group . COST_MONEY" 
android: protectionLe ve l="dangerous " /> 

</manifest> 

Attraverso l'attributo android manie Viene specificato il nome del permesso, che e rappresentato da 
una semplice string. Si tratta spesso di un nome legato a quello dell'applicazione o funzionalità che lo 
stesso protegge. Un'informazione fondamentale e quella descritta dall'attributo obbligatorio 
android : protectionLevei, che consente di esprimere il livello di rischio indicando la procedura che il 
sistema seguirà per detenninare se tale permesso debba essere concesso oppure no all'applicazione 
che ne fa richiesta. I possibili valori sono elencati nella Tabella 10.1. 

Tabella 10.1 I possibili livelli di protezione. 




normal 


0 


dangerous 


1 


signature 


2 


signatureOrSystem 


3 



Il livello di protezione definito normal e quello più basso e indica che il permesso e relativo a 
un'operazione limitata alla sandbox dell'applicazione che lo ha definito. Essa ha un rischio rninimo per 
quello che riguarda il sistema e i dati dell'utente. In questo caso il sistema autorizza automaticamente 
questo tipo di permessi in fase di installazione senza richiedere all'utente un consenso esplicito ma 
visualizzandoli in modo chiaro. Il livello di protezione definito come dangerous riguarda invece dei 
permessi che permettono l'accesso alle informazioni dell'utente o a particolari funzionalità del sistema. 
Si tratta di operazioni potenzialmente rischiose che quindi devono essere per forza visualizzate 
all'utente, il quale ne deve dare esplicita conferma. Molto importanti sono i permessi definiti con un 
livello di protezione signature: possono essere concessi solamente ad applicazioni firmate con lo 
stesso certificato utilizzato per firmare l'applicazione che fornisce le funzionalità richieste. Nel caso in 
cui il certificato fosse lo stesso, si tratta comunque di permessi che vengono concessi in automatico. 
Questo tipo di permessi si usano spesso nel caso di gestione di account attraverso un componente 
standard che vedremo nel Capitolo 13 e che si chiama AccountManager. Si tratta del tipo di 
autorizzazioni consigliato nel caso di applicazioni che necessitino di un elevato grado di sicurezza. Il 
livello di protezione signatureOrSystem e quello relativo ad autorizzazioni concesse alle API di 
sistema o comunque ad applicazioni firmate conio stesso certificato. Si tratta di permessi utilizzati da 
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chi realizza versioni personalizzate della piattaforma. 

L'attributo android:permissionGroup e opzionale e permette semplicemente di indicare a quale 
gruppo di autorizzazioni appartiene quella appena definita. Il gruppo può essere uno tra quelli 
predefiniti oppure uno personalizzato definito dallo sviluppatore. Esistono infine gli attributi 
android : label e android : description, che permettono rispettivamente di dare un nome e una 
descrizione al permesso. Sono quelle informazioni che vengono visualizzate all'utente in fase di 
installazione dell'applicazione. Si tratta spesso di risorse internazionalizzate attraverso il meccanismo 
di gestione delle risorse tipico di Android. 

Il meccanismo dei permessi viene utilizzato unitamente ai diversi componenti della piattaforma e 
fornisce un valido strumento di sicurezza. 

Permission e activity 

Come descritto in precedenza, un' activity viene definita all'interno del documento 
AndroidManif est . xml e può essere attivata sia in modo esplicito sia attraverso il processo di intent 
resolution. Nel primo caso l'applicazione chiamante deve conoscere esattamente il nome della classe 
che descrive l'attività, oltre che possederlo nel proprio classpath. Sono activity private a cui non si 
può accedere da altre applicazioni, le quali spesso non ne conoscono il nome oltre che non 
possederne ilbytecode corrispondente. Nel secondo caso, l'attività che viene lanciata dovrà 
dichiarare un intent filter compatibile con l'intent lanciato per la sua visualizzazione. Le regole sono 
quelle di intent resolution ma possono comunque essere ampliate da alcune considerazioni di sicurezza 
che permettono da un lato di rendere il componente privato e dall'altro di richiedere l'utilizzo di un 
insieme di permessi 

Un' activity, che definisce un intent filter, e di default pubblica e quindi può essere avviata da una 
qualunque applicazione che lanci un intent appropriato. Attraverso l'attributo android: exported e 
comunque possibile, attraverso il valore false, rendere tale attività privata della sola applicazione che 
la definisce. Attraverso l'attributo android:permission SipuÓ inoltre fare in modo che l'avvio 
dell'attività avvenga solamente da quelle applicazioni che dispongono del permesso corrispondente. 
La verifica siali' effettiva accessibilità dell' activity viene eseguita nel metodo oncreate ( ) della classe 
Activity. In caso contrario si ha il sollevamento di una security exception. Per quanto detto e buona 
norma che solamente le activity che forniscono funzionalità utili a più applicazioni vengano definite 
pubbliche e siano accessibili anche da applicazioni diverse da quella che le definiscono. Nel caso di 
attività utili solamente all'interno dell'applicazione e bene utilizzare il valore false per l'attributo 
android : exported. Nel caso in cui le activity permettano l'interazione con funzionalità di sistema o 
comunque sensibili e consigliabile definire un opportuno permesso da impostare come valore del 
corrispondente attributo. 

Permessi e servizi 

Nel caso dei servizi le restrizioni riguardano le applicazioni che possono avviare un servizio o 
eseguirne un'operazione di binding. Anche qui si tratta di informazioni che vengono definite all'interno 
del file AndroidManif est . xml in corrispondenza della definizione del servizio stesso. Analogamente a 
quanto avviene per le activity, anche i servizi sono pubblici di default. Anche qui esiste però l'attributo 
android : exporte d che, se valorizzato a false, rende tali servizi privati e quindi accessibili solamente 
dall'applicazione che lo ha definito. Analogamente alle activity, esiste anche l'attributo 
android : permission che permette la definizione del permesso che le applicazioni che intendono 
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interagire con il servizio devono possedere. La verifica della possibilità di interagire con un service 

avviene COn i metodi startService () , stopService O e bindService ( ) della classe Service. In CaSO 

contrario si ha il sollevamento di una security exception. Analogamente a quanto detto per le activity, 
è buona norma che solamente i service che forniscono funzionalità utili a più applicazioni vengano 
definiti pubblici e siano accessibili anche da applicazioni diverse da quella che li definiscono. Nel caso 
di servizi utili solamente all'interno dell'applicazione e bene utilizzare il valore false per l'attributo 
android : exported. Nel caso in cui i servizi permettano l'interazione con funzionalità di sistema o 
comunque sensibili. Si consiglia di definire un permesso da impostare come valore del corrispondente 
attributo. 

Permessi e BroadcastReceiver 

A differenza dei componenti precedenti, un BroadcastReceiver viene sempre definito come 

pubblico anche se i permessi permettono comunque di decidere quale applicazione può inviare degli 
intent attraverso il metodo sendBroadcast ( ) . Un overload di questo metodo consente infatti di 
impostare il permesso che 1 BroadcastReceiver devono aver definito per poter ricevere F intent 
stesso. A differenza di quanto descritto in precedenza per i servizi e per le activity, la mancata 
corrispondenza dei permessi non porta a un'eccezione di sicurezza ma impedisce semplicemente 
l'invocazione del BroadcastReceiver, il quale non riceverà quindi l'intent inviato. Per questo tipo di 
componenti è preferibile che solamente i BroadcastReceiver in grado di fornire funzionalità a più 
applicazioni non definiscano alcun permesso. Per gli altri e bene definire dei permessi e quindi 
utilizzarli per il lancio dell' intent. 

Permessi e content provider 

Anche nel caso dei content provider esiste la possibilità di definirli come risorse pubbliche (il 
defàult) o private di una o più applicazioni. Anche qui si può usare l'attributo android: exported 
specificando il valore false nel caso di repository privati. Per quello che riguarda l'accesso ai dati, i 
content provider definiscono due diversi attributi che permettono di distinguere le operazioni di lettura 
da quelle di scrittura. Attraverso l'attributo android : readPermission e possibile specificare i 
permessi che dovranno essere posseduti dalle applicazioni che intendono leggere le informazioni. 
Attraverso l'attributo android :writePermission sipossono invece definire i content provider che 
dovranno essere posseduti dalle applicazioni che intendono scrivere sul repository. Sono permessi 
che vengono verificati a ogni operazione di accesso. È buona norma che solamente i content provider 
che forniscono dati utili a più applicazioni vengano definiti pubblici e quindi siano accessibili anche da 
applicazioni diverse da quella che li definiscono. Nel caso di repository utili solamente all'interno 
dell'applicazione e bene utilizzare il valore false per l'attributo android: exported. Nel caso di 
content provider pubblici e sempre preferibile distinguere i permessi relativi all'accesso in lettura da 
quelli in scrittura attraverso la definizione degli attributi corrispondenti. 

Gestione dei permessi 

In alcune applicazioni sviluppate in questo e nei capitoli precedenti abbiamo sottolineato la 
necessità di definire quelli che abbiamo chiamato permessi senza però fornire indicazioni precise sul 
loro significato. Dal paragrafo precedente sappiamo che si tratta di modalità con cui una particolare 
applicazione dichiara l'utilizzo di una funzionalità che prima abbiamo definito "sensibile". In pratica, se 
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un' applicazione deve accedere alla rubrica dei contatti di un dispositivo deve dichiararlo attraverso il 
relativo permesso. Stesso comportamento dovrà essere seguito nel caso della volontà di accedere 
alla Rete, di attivare la videocamera o di iniziare una chiamata telefonica. Ma dove viene poi utilizzata 
questa informazione? È sufficiente dichiarare il relativo permesso nel documento 
AndroidManif est . xml per poter usare una particolare operazione sensibile? Certo che no. 
L'informazione così definita viene usata sì a runtime per consentire l'operazione all'applicazione che 
ne ha fatto richiesta ma solo dopo che, in fase di installazione l'utente ne ha dato esplicito consenso. E 
interessante notare come l'eventuale consenso o la negazione da parte dell'utente nei confronti di un 
particolare permesso decisa al momento dell'installazione non viene più riproposta all'utente a 
runtime. Questo significa che se l'utente ha consentito l'installazione di un'applicazione che ha 
richiesto l'accesso alla Rete, questa applicazione potrà sempre accedere a questa funzionalità a 
runtime. Se l'operazione non è consentita viene sollevata è una security exception, a meno che non si 
tratti di un BroadcastReceiver per il quale viene solamente visualizzato in messaggio di log. 

Esistono dei permessi definiti dall'ambiente di Android e altri che è possibile definire in modo 
personalizzato. Il lettore potrà consultare la documentazione ufficiale relativa alla classe statica interna 
android. Manif est. permission per un elenco completo e aggiornato di tutti i permessi predefiniti che 
si possono richiedere. Possiamo invece vedere come ciascun permesso sia descritto da un nome del 
tipo 

android. permission. <SPECIFICA_PERMISSION> 

e venga specificato nel documento AndroidManif est. xml attraverso l'utilizzo dell'elemento <uses- 
permission/>. Per esempio, se volessimo dichiarare la volontà di inviare un SMS dopo un accesso 
all'elenco dei contatti del dispositivo dovremmo definire queste dichiarazioni: 

<manif est xmlns : android="http : / / schema s . android . com/apk/ re s /android" 
package="<package applicazione>" > 

<uses-permission android : name=" android . permission . SEND_SMS" /> 
<uses-permission android : name= " android . permission . READ_CONTACTS" /> 

< /mani f est > 

dove abbiamo messo in evidenza che l'elemento <uses-permission/> è figlio dell'elemento 
<manifest/> e non è contenuto in altri relativi per esempio a un'application o a un'activity. Verificare 
l'utilizzo di queste definizioni sarà molto semplice: basterà tentare una connessione senza aver 
specificato il permesso android. permission. internet per ottenere una security exception con 
conseguente crash dell'applicazione. 

Creazione di permessi personalizzati 

Come detto prima, è possibile definire i propri permessi al fine di limitare l'accesso a deteirninate 
operazioni o l'utilizzo di particolari componenti. Un esempio è quello che permette, per esempio, di 
eseguire deteirninate activity solamente da alcune applicazioni Stessa cosa nel caso di detenninati 
servizi o content provider. Anche qui il primo passo consiste nella definizione dei permessi all'interno 
del documento AndroidManif est . xml utilizzando questa volta l'elemento <permission/>. Dalla 
documentazione vediamo come l'elemento < P ermission/> preveda una serie di attributi, il più 
importante dei quali è il nome, che osserva la convenzione 

<nome package applicazione> . permission . <NOME_PERMISSION> 

che è ottenuta concatenando il nome del package con permission e il nome dello stesso in 
maiuscolo. 

445 



A parte le scontate informazioni relative all'etichetta, all'icona e alla descrizione, è importante 
specificare il significato degli attributi relativi al Protection Level e al Permission Group. Il primo 
consente di indicare come il sistema si dovrà comportare al momento dell'installazione 
dell'applicazione per richiedere eventualmente il consenso all'utente. Il valore di default di questo 
attributo è normal e indica un consenso automatico da parte del sistema. Si tratta di un permesso che 
deve essere visualizzato all'utente che sta installando l'applicazione in modo che questo possa 
comunque interrompere l'operazione. Se a un permesso viene associato via. Protection Level 
identificato dal valore dangerous, il sistema chiederà invece sempre conferma esplicita all'utente 
prima dell'installazione. Molto interessante è il valore signature, analogo a normal ma limitatamente 
alle sole applicazioni firmate con lo stesso certificato usato per firmare l'applicazione che ha definito il 
permesso. Infine, il valore signatureorsystem che, in più rispetto al valore precedente, permette di 
concedere il permesso anche alle applicazioni del sistema. Quest'ultimo è un tipo di permesso usato 
più che altro dai vendor che rilasciano le immagini della piattaforma. L'informazione relativa al 
Permission Group serve invece semplicemente per raggruppare i permessi in fase di presentazione 
all'utente durante il processo di installazione. Ameno di casi particolari, si consiglia di utilizzare i 
gruppi già presenti 

Utilizzo di un permesso personalizzato 

I permessi così definiti vanno utilizzati per restringere l'utilizzo a determinate funzionalità o 
componenti. Per farlo si può ricorrere all'attributo android: permission applicato al componente 
corrispondente il cui valore è il nome del permesso necessario al suo utilizzo. Se applicato a 
un'activity e all'elemento <activity/> il controllo viene fatto al momento del suo avvio attraverso 
startActivity o o startActivityForResuit o generando una security exception in caso di 
negazione. Per i servizi, e quindi per gli elementi di tipo <service/>, il controllo avviene in occasione 
dell'esecuzione delle operazioni che ne permettono l'avvio o ilbinding. Anche in questo caso è 
possibile venga sollevata una security exception. Come accennato in precedenza, interessante è il 
caso in cui l'attributo viene utilizzato per un BroadcastReceiver e poi con l'elemento <receiver/>. 
Qui il controllo sui permessi viene eseguito dopo il ritorno dal metodo sendBroadcast o senza 
generare alcuna eccezione nel caso di negazione. In quel caso l'intent non viene semplicemente 
recapitato al componente. Questo ci permette di controllare l'insieme deifcroadcastReceiver che, in 
corrispondenza alla chiamata del metodo sendBroadcast o , dovrà ricevere l'intent. Ricordiamo infatti 
che la firma del metodo è la seguente: 

public abstract void sendBroadcast (Intent intent, String receiverPermission) 

e prevede la definizione del permesso necessario come secondo parametro. 
Infine, per quello che riguarda i content provider esiste un meccanismo leggermente più complesso 
che consente di impostare i permessi richiesti sia per la lettura sia per la scrittura rispettivamente 

attraverso gli attributi android: readPermission e android:writePermission. È importante ricordare 

che nel caso in cui non si sia in possesso del diritto di lettura ma solo di quello di scrittura, 
quest'ultimo non si sovrappone al primo e quindi permetterà solo la scrittura e non la lettura. A 
seconda del tipo di permesso negato, si avrà la generazione di una security exception nelle operazioni 
che permettono di ottenere un riferimento al content provider oppure in corrispondenza delle 
operazioni stesse (per esempio query ( ) ). 

Per quello che riguarda i content provider, Android fornisce un meccanismo di gestione dei 
permessi che va oltre quello descritto finora e che ha l'obiettivo di risolvere impossibile problema che 
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si può verificare in casi molto comuni di app Reazioni Consideriamo per esempio un' applicazione che 
accede ai contatti del telefono tra le cui informazioni vi sono anche delle foto. L'accesso a queste 
informazioni dovrà richiedere il relativo permesso in quanto sono legate alla privacy dell'utente. Se 
volessimo visualizzare la foto attraverso un'attività che non appartiene a quella applicazione, essa 
dovrebbe richiedere gli stessi permessi della precedente anche se la visualizzazione di ima foto non è 
legata all'insieme di contatti A tale proposito, solamente per i content provider, Android permette ima 
gestione dei permessi basati sul singolo URI della risorsa da leggere o scrivere. Facendo riferimento a 
un' applicazione che, per esempio, accede ai contatti e richiede il lancio dell'attività per la 
visualizzazione della foto, si potrà impostare come flag del relativo intent imo o entrambi i valori 

Intent . FLAG_GRANT_READ_URI_PERMISSION 0 Intent . FLAG_GRANT_WRITE_URI_PERMISS ION. IlprimO 

indica che l'attività di destinazione potrà accedere in lettura a quello che è il contenuto associato 
all'URI passato attraverso l'intent. Il secondo valore indica che il permesso è relativo all'operazione 
di scrittura. Un' ultima nota: un content provider può decidere di abilitare una gestione dei permessi di 
questo tipo attraverso l'attributo android : grantUriPermissions. 

Accesso a servizi HTTP 

Abbiamo più volte ricordato come Android utilizzi molte librerie open source, e questo avviene 
anche per quello che riguarda l'invocazione di servizi web attraverso il protocollo HTTP. Tra le API 
disponibili vi sono infatti quelle relative all'Httpciient di Apache che permette di accedere a servizi 
HTTP in modo molto semplice, come vedremo di seguito. Innanzitutto notiamo come Httpciient sia 
un' interfaccia del package org . apache . http . client, che ha tra le sue principali operazioni un insieme 
di overload di un metodo execute ( ) , che ci porta a pensare, correttamente, che si tratti di 
un' implementazione del pattern GoF Command. In pratica si tratta di un oggetto attraverso il quale è 
possibile inviare delle richieste come se fossero dei comandi da eseguire a cui corrisponde la 
creazione di risposte il cui riferimento viene ottenuto secondo diverse modalità. L'operazione più 
semplice è 

public abstract HttpResponse execute (HttpUriRequest request) 

che consente di eseguire un comando le cui informazioni sono incapsulate all'interno di un oggetto 
di tipo HttpUriRequest, ottenendo come risposta un insieme di informazioni incapsulate all'interno di 
un HttpResponse. Come detto, si tratta della versione più semplice che assume l'utilizzo del contesto 
di default e l'accesso a un host le cui informazioni sono contenute nella richiesta stessa. Per contesto 
HTTP si intende uno spazio condiviso tra la richiesta e la relativa risposta usato spesso dall'ambiente 
stesso e descritto da ima specializzazione dell'interfaccia HttpContext. Le diverse implementazioni 
utilizzate differiscono, per esempio, per il fatto di essere thread safe oppure no. 

NOTA 

Come sappiamo il comportamento corretto di un oggetto può dipendere dal fatto che questo venga 
utilizzato da un unico thread o da più thread contemporaneamente. Nel caso in cui il corretto 
funzionamento sia garantito anche in un contesto multithreading, si parla di thread safe. Spesso un 
oggetto di questo tipo usa dei meccanismi di sincronizzazione che però vanno a influire sulle 
prestazioni. Da una parte c'è l'esigenza di garantire l'integrità di un dato, dall'altra quella di rendere 
un'applicazione sufficientemente performante. 

La forma più complessa di operazione execute ( ) è invece la seguente: 

public abstract T execute (HttpHost target, HttpRequest request, 

ResponseHandler<? extends T> responseHandler, HttpContext context) 

che notiamo essere descritta attraverso un metodo generico. Il primo parametro è un oggetto di 
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tipo HttpHost che in sintesi non tà altro che incapsulare le informazioni del server a cui accede, quelle 
che prima erano nella stessa richiesta. Esso contiene semplicemente le informazioni relative a quello 
che si chiama schema e che è tipicamente http, al nome dell'host e alla relativa porta. Si tratta di una 
classe final, che quindi non può essere ulteriormente specializzata. Usuo significato è quello di 
andare raoverriding rispetto alle stesse informazioni che vedremo saranno incapsulate nell'oggetto 
HttpRequest passato come secondo parametro. Osservando le API vediamo come si tratti di 
un'interfaccia che presenta diverse interessanti implementazioni tra cui quelle descritte dalle classi 
HttpGet e HttpPost. Questo ci consente di dedurre come il metodo utilizzato nell'invocazione al 
servizio dipenderà dalla particolare implementazione dell'interfaccia HttpRequest che utilizzeremo 
all'interno di una delle operazioni execute o . 
NOTA 

Il lettore potrà verificare l'esistenza di implementazioni relative anche ai metodi head, options, put e 

TRACE. 

Il terzo parametro è una particolare implementazione dell'interfaccia ResponseHandler, la quale 
prevede la definizione dell'unica operazione 

public abstract T handleResponse (HttpResponse response) 

In pratica, un particolare ResponseHandler associato al tipo t è un oggetto in grado di creare un 
oggetto dello stesso tipo t a partire dalla HttpResponse ottenuta dall'invio di una particolare richiesta. 
Per comprendere meglio, possiamo dire che un'implementazione dÌResponseHandier<strìng> è un 
oggetto in grado di estrarre una string dalla risposta ottenuta a seguito dell'invio della richiesta 
HTTP. Un'implementazione dÌResponseHandier<LocaiDataModei> è un oggetto che può costruire 
un'istanza della classe LocaiDataModei a partire da una risposta ottenuta a seguito dell'invio di una 
richiesta HTTP. L'ultimo parametro è infine il riferimento al suddetto contesto. 

NOTA 

Il lettore potrà verificare la presenza di diversi overloadde\ metodo execute o che differiscono per la 
presenza o meno di alcuni degli oggetti descritti. 

L'ultima considerazione riguarda le caratteristiche di una risposta descritte dall'interfaccia 
HttpResponse, che ha tra le sue proprietà principali quelle di entity e status line. Un' entity, che in 
realtà può essere associata anche a una richiesta, rappresenta appunto un tipo di informazione 
contenuta in qualche modo in un messaggio HTTP. Per comprenderne il significato basta dare 
un'occhiata a quelle che sono alcune delle implementazioni dell'interfaccia HttpEntity. Per esempio, 
la classe StringEntity descrive un'entità le cui informazioni provengono da un contenuto testuale, 
mentre la classe FiieEntity descrive un'entità le cui informazioni provengono da un file. In generale 
le entity possono essere classificate in base a quello che le specifiche chiamano content, ovvero 
l'inputstream da cui vengono lette le corrispondenti informazioni. Atale proposito esiste la 
classificazione in entità di tipo: 

• streamed; 

• self-contained; 

• wrapping. 

Le prime sono quelle il cui content non è ripetibile, ovvero quelle che possono essere lette una sola 
volta dallo stream proveniente di solito da una connessione. Quelle self-contained sono quelle 
ottenute da informazioni non legate a un particolare stream e quindi solitamente ripetibili Infine le 
wrapping sono quelle entità ottenute da altre. Vedremo l'importanza delle entity nel caso di utilizzo 

448 



del metodo post . 

Infine la status line di ima risposta, le cui informazioni sono incapsulate all'interno di un oggetto di 
tipo statusLine, non sono altro che le stesse informazioni presenti nella prima riga di una risosta 
HTTP, ovvero quelle relative a: 

• codice della risposta; 

• versione del protocollo ; 

• descrizione del messaggio corrispondente. 

Le informazioni contenute in oggetti di tipo statusLine potrebbero essere quelle corrispondenti, 
per esempio, al codice 200 per una risposta corretta oppure al codice 404 per una risorsa assente. 
Non ci resta che descrivere la modalità con cui sia possibile eseguire delle richieste HTTP, è sia nella 
modalità GET sia in POST, attraverso l'utilizzo diunHttpciient. 

Invio di richieste in GET 

Da quanto descritto nel paragrafo precedente, l'invio di una richiesta HTTP nella modalità GET a 
un server attraverso un Httpciient diventa cosa molto semplice. In un'ottica REST si tratta poi di 
una tipologia di richiesta che viene fatta con lo scopo di accedere allo stato di una risorsa remota 
senza modificarlo, come può avvenire invece nel caso di richieste di tipo POST. Come esempio di 
richiesta GET abbiamo implementato il servizio di login tramite il metodo ìogin ( > della classe 
LoginService, COSI da accedere a un servizio remoto di cui è noto il protocollo. Supponiamo che 
FURI della richiesta sia il seguente 

<host>/path/ login ?username=<username>&password=<md5-password> 

e il risultato sia del tipo: 

{ 

"result" : "KO", 

"message" : "messaggio di errore" 

} 

nel caso di login errato del seguente tipo: 
{ 

"result" : "OK", 
"username" : "<username>", 
"email" : "<email>" , 
"birthDate" : birthdate_as_long, 
"location" : "<my location>" 

} 

in caso di successo. Notiamo come, al posto della password in chiaro, si passi il corrispondente 
MD5. 
NOTA 

Per il test dei due casi abbiamo messo a disposizione un servizio di login fittizio all'indirizzo 

http : / /www.massimocarli . eu/android/logìn.php, I I quale risponde in modo affermativo solamente nel caso in 
cui lo username sia pippo e la password corrisponda all'Ivi D5 della stringa android. 

In questi casi il primo passo consiste nella definizione dei diversi URL di connessione all'interno di 
una risorsa in modo da renderne possibile la modifica in modo veloce, magari utilizzando gli strumenti 
che Android Studio sta iniziando a mettere a disposizione sfruttando le caratteristiche di Gradle come 
tool dibuild. Per questo motivo abbiamo definito la seguente risorsa all'interno del file conf.xml in 

/main/ res/values! 

<resources> 

<! — Conf iguration URL — > 
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<string name=" login_url">http : / /www.massimocarli . eu/ andrò id/ login . php? 
username=$l%s& password=$2%s</ string> 
</ resources> 

Vediamo come si siano utilizzati dei parametri in modo da rendere più veloce la composizione 
deU'URLuna volta ottenuti username e password. 

Il secondo step consiste nell'implementazione di una classe di utilità che ci permetta di calcolare 
FMD5 di una particolare string. Per questo motivo abbiamo implementato la classe MDSutiiity nel 
package utii: 

public final class MD5Utility { 

private static final int FF_HEX_VALUE = OxFF; 

private MD5Utility() { 

throw new AssertionError ( "Never instantiate this!"); 

} 

public static String md5 (String src) { 
try { 

MessageDigest digest = MessageDigest . getlnstance ( "MD5" ) ; 

digest . update (src . getBytes ( ) ) ; 

byte[] messageDigest = digest . digest () ; 

StringBuffer hexString = new StringBuf fer () ; 

for (int i = 0; i < messageDigest . length; i++) { 

hexString . append ( Integer . toHexString (FF_HEX_VALUE 
& messageDigest [i] ) ) ; 

} 

String md5 = hexString. toString() ; 

return md5; 
} catch (NoSuchAlgorithmException e) { 
e . printStackTrace ( ) ; 

} 

return nuli; 

} 

public static boolean checkMD5 (String str, String md5) { 
String pwdMD5 = md5(str); 
boolean success = md5 . equals (pwdMD5 ) ; 
return success; 

} 

} 

Il metodo statico md5 ( ) è proprio quello che là a caso nostro per il calcolo della stringa da inviare, 
al posto della password, come parametro della nostra richiesta di login. A questo punto andiamo al 
nostro metodo di login ( ) della classe Loginservice, per il quale occorre prendere una decisione 
importante: è un'operazione che non dovrà essere eseguita all'interno del thread principale. Si 
richiede quindi di decidere se la creazione del thread in cui eseguire questa operazione debba essere 
del metodo di login o o dell'oggetto chiamante. Nel nostro caso la scelta ci porta a creare questo 
thread attraverso un Asyndask nell'attività di login, per cui il Loginservice dovrà semplicemente 
eseguire la richiesta e poi elaborare il risultato in base alla risposta. Intanto il metodo di login ( ) 
diventa questo: 

public UserModel login (final Context context, final String username, 
final String password) { 
UserModel userModel = nuli; 

final String loginUrl = context . getResources ( ) 

. get String (R . string . login_url, username, MD5Utility . md5 (password) ) ; 
HttpClient httpClient = new DefaultHttpClient () ; 
HttpGet request = new HttpGet (loginUrl) ; 

try { 

userModel = httpClient .execute (request, mUserModelResponseHandler) ; 

} catch (IOException e) { 
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e . printStackTrace () ; 

} 

return userModel; 

} 

Innanzitutto notiamo come si sia dovuto aggiungere un parametro per il Context, di cui avremo 
bisogno per accedere all'URL che abbiamo inserito appunto tra le risorse. I passi successivi sono 
abbastanza automatici e precedono la creazione della particolare istanza di Httpciient, che nel 
nostro caso è la più semplice, descritta dalla classe DefauitHttpciient. Si tratta del componente che 
ha il ruolo di command executor e che andrà a eseguire il comando che qui è dato da un'istanza della 
classe HttpGet a cui abbiamo passato l'URL a cui inviare la richiesta. La richiesta è stata inviata 
attraverso il metodo execute o, che ha due parametri II primo è il nostro comando e quindi l'oggetto 
HttpGet, mentre il secondo è un oggetto che implementa l'interfaccia ResponseHandler e che 
sostanzialmente sa come elaborare la risposta per creare l'oggetto di tipo userModel. Nel nostro caso 
questo oggetto è stato implementato come segue: 

private ResponseHandler<UserModel> mUserModelResponseHandler = 

new ResponseHandler<UserModel> ( ) { 

SOverride 

public UserModel handleResponse (HttpResponse httpResponse) 
throws ClientProtocolExceptìon, IOException { 
UserModel userModel = nuli; 

InputStream content = httpResponse . getEntity () . getContent () ; 

byte[] buffer = new byte [1024]; 
int numRead = 0; 

ByteArrayOutputStream baos = new ByteArrayOutputStream ( ) ; 
while ( (numRead=content . read (buffer ) ) !=-l) { 
baos .write (buffer, 0, numRead); 

} 

content . dose ( ) ; 
try { 

JSONObject resultAsUson = 

new JSONObject (new String (baos . toByteArray ())) ; 
final String result = resultAsJson 

. opt String ( "result" , KO_RESULT) ; 
if (KO_RESULT.equals (result) ) { 

userModel = UserModel 

. f romError (resultAsJson . optStrìng ( "message" ) ) ; 

} else { 

final long birthDate = resultAsJson . optLong ( "birthDate" , 0) ; 

if (birthDate > 0) { 

userModel = UserModel . create (birthDate) 

.withEmail (resultAsJson . optString ( "email" ) ) 
.withUsername (resultAsJson . optString ( "username" ) ) 
.withLocation (resultAsJson . optString ( "location" ) ) ; 

} else { 

userModel = UserModel 

. f romError ( "Error in birthDate data!"); 

} 

} 

} catch ( JSONException e) { 
e . printStackTrace ( ) ; 

userModel = UserModel . f romError ( "JSON error: " 

+ e . getMessage ( ) ) ; 

} 

return userModel; 

} 

}; 

Si tratta dell'implementazione che contiene tutta la logica di elaborazione della risposta dal server 
per la creazione dell'oggetto userModel o per la visualizzazione di un messaggio di errore. 

NOTA 

A tale proposito il lettore noterà come la classe UserModel sia stata modificata in modo da prevedere 
la possibilità di memorizzare un messaggio di errore. 
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Possiamo pensare al metodo precedente come composto di due parti La prima consiste nella 
lettura dell'output come stringa a partire dall'oggetto di tipo HttpResponse da cui si leggono le 
informazioni attraverso UT1 Input Stream. La seconda parte consiste invece nel parsing del 
corrispondente documento JSON attraverso il parser nativo della piattaforma Andro id. 

Al termine dell' esecuzione del metodo di login avremo quindi un oggetto userModei che potrà 
contenere un messaggio di errore oppure le informazioni relative a un login eseguito con successo. 
Altre cose da notare sono l'utilizzo del campo result e della classe di utilità relativa alla gestione 
dell'MD5 per la password. 

A questo punto mancano ancora due importanti step. Il primo è immediato e consiste, anche alla 
luce di quanto imparato nella prima parte del capitolo, nella necessità di dichiarare il permesso 
attraverso la seguente definizione nel file di configurazione KndroidManif est . xml: 

<uses-permission android: name="android.permission . INTERNET" /> 

Il secondo consiste invece nella realizzazione diun Asyndask che ci permetta di eseguire il metodo 
di login o in un thread diverso da quello principale. 
NOTA 

Il lettore a questo punto può verificare come un'operazione di connessione all'interno del thread 
principale porti a un errore e quindi al crash dell'applicazione. 

Andiamo allora alla classe LoginActivity e implementiamo l'AsyncTask in modo da eseguire il 
metodo di login ( ) in background: 

private class LoginAsyncTask extends AsyncTask<String, Void, UserModel> { 
SOverride 

protected void onPreExecute ( ) { 
super . onPreExecute ( ) ; 

mProgressAlertDialog = new ProgressAlertDialog ( ) ; 
mProgressAlertDialog . show (getSupportFragmentManager ( ) , 
PROGRESS_DIALOG_TAG) ; 

} 

SOverride 

protected UserModei doInBackground (String . . . strings) { 
final String username = strings [0]; 
final String password = strings [1]; 
final UserModei userModei = LoginService . get ( ) 

. login (getApplicationContext () , username, password); 
return userModei; 

} 

SOverride 

protected void onPostExecute (UserModei userModei) { 
super . onPostExecute (userModei) ; 
mProgressAlertDialog . dismiss () ; 

if (userModei != nuli && ! userModei . hasError () ) { 

Intent resultlntent = new Intento," 

result Intent .putExtra (USER_DATA_EXTRA, userModei) ; 

setResult (RESULT_OK, resultlntent) ; 

finish ( ) ; 
} else { 

mErrorTextView . setText (userModei . getErrorMessage ( ) ) ; 
mErrorTextVìew. setVisibility (View. VISIBLE) ; 

} 

} 

} 

Notiamo come l'invocazione del metodo di login o avvenga ora nel metodo doInBackground ( ) e 
di come la gestione del risultato, con relativa gestione dell'errore, avvenga invece all'interno del 
metodo onPostExecute () . Il metodo doLogino invocato a seguito della pressione del pulsante di 
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login si semplifica di molto, in quanto contiene semplicemente la logica di validazione formale di 
username e password e quindi l'invocazione dell' AsyncTask attraverso queste due righe di codice: 

mLoginAsyncTask = new LoginAsyncTask ( ) ; 
mLoginAsyncTask . execute (username, password) ; 

Ora abbiamo tutto per eseguire il login attraverso l'invio di una richiesta di tipo GET a un server 
che potrà implementare tutta la logica che si vuole. 

Condivisione di uno stesso HttpCIient 

Come più volte ripetuto, in un'applicazione Andro id le performance sono molto importanti Questo 
presuppone un modo di programmare basato sull'ottimizzazione delle risorse che si hanno a 
disposizione. Nel paragrafo precedente abbiamo implementato una soluzione che ha, da questo punto 
di vista, il difetto di creare un client per ciascuna richiesta. Una soluzione al problema è invece quella 
di creare un'unica istanza dell'implementazione di Httpciient e condividerla tra più componenti di 
una stessa applicazione, la quale può essere composta, come sappiamo, da più activity. Oltre al 
processo all'interno del quale vengono eseguite, tutte le activity di un'applicazione condividono una 
stessa istanza di un oggetto di tipo Application del package android.app. 

NOTA 

Facendo un'analogia con quanto avviene per il web tier di un'applicazione enterprise, possiamo 
pensare ad Application come a qualcosa di simile al servietcontext, ovvero un contenitore di oggetti 
condiviso tra componenti, in quel caso web, diversi il cui ciclo di vita è gestito dal container. 

Come nel caso delle attività, anche un'Application è sottoposta a un ciclo di vita da parte 
dell'ambiente e può essere definita attraverso il corrispondente elemento <appiication/> all'interno 
del file AndroiManifest .xml. La realizzazione di una particolare Application da associare 
all'applicazione è quindi il luogo ideale dove inserire oggetti che possono essere condivisi dalle varie 
attività. 

Se il client può essere condiviso tra thread diversi servono anche dei meccanismi che ne 
permettano un utilizzo corretto; fortunatamente le API di Apache ci permettono di gestire la cosa 
senza grossi problemi. A ciascun Httpciient è infatti associato un oggetto responsabile delle 
connessioni verso il server, il quale viene descritto da un'implementazione dell'interfaccia 
ClientConnectionManager. La responsabilità di questo oggetto è quella di gestire le connessioni 
utilizzate per l'accesso ai vari server in relazione ai diversi tipi di protocollo. Per rendere l'oggetto 
Httpciient utilizzabile in un contesto multithreading non dovremo far altro che assegnargli 
un'implementazione del tu entConnectionManager descritta dalla classe 

ThreadSafeClientConnManager. Iniziamo COn il Creare la particolare Specializzazione di Application 

che abbiamo descritto attraverso la classe ughoAppiication in cui abbiamo fatto Yoverriding di tre 
importanti metodi di callback. Come per altri componenti, la notifica dell'avvenuta creazione avviene 
attraverso l'invocazione del metodo: 

public void onCreateO 

Il metodo 

public void onTerminate ( ) 

viene invece utilizzato solo in un ambiente emulato e quindi mai invocato su un dispositivo. È il 
metodo invocato quando il processo associato all' app Reazione viene eliminato. Infine, in situazioni con 
scarsa disponibilità di memoria, viene invocato il metodo 

public void onLowMemory ( ) 
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all'interno del quale dovremo eseguire tutte le operazioni che permettono di liberare l'eventuale 
memoria allocata. Di solito con questo metodo si svuotano le eventuali cache o si liberano le risorse 
non necessarie alfine di evitare, per quanto possibile, l'odiato errore dioutofMemoryError. 

Nella nostra implementazione abbiamo fatto in modo di creare il particolare Httpciient in 
corrispondenza del metodo oncreate ( ) , rilasciando le risorse negli altri casi. Per la gestione del 
nostro Httpciient abbiamo creato la classe ThreadSafeHttpciientFactory, che ci fornisce anche 
l'occasione per alcune osservazioni sulle enum Java: 

public enum ThreadSafeHttpciientFactory { 
INSTANCE; 

private static final ìnt TIMEOUT = 60000; 

private static final int HTTP_PORT = 80; 

private static final int HTTPS_PORT = 443; 

private static final String HTTP_SCHEMA = "http"; 

private static final String HTTP S_SCHEMA = "https"; 

private HttpClient httpClient; 

private ThreadSaf eHttpClientFactory ( ) { 
httpClient = createHttpClient () ; 

} 

public HttpClient getThreadSaf eHttpClient ( ) { 
if (httpClient == nuli) { 

httpClient = createHttpClient () ; 

} 

return httpClient; 

} 

public void releaseO { 
httpClient = nuli; 

} 

private HttpClient createHttpClient ( ) { 

HttpParams httpParams = new BasicHttpParams ( ) ; 

HttpProtocolParams . setVersion (httpParams, HttpVersion . HTTP_1_1 ) ; 
HttpProtocolParams . setContentCharset (httpParams, 

HTTP . DEFAULT_CONTENT_CHARSET ) ; 
SchemeRegistry schemeRegistry = new SchemeRegistry () ; 
Scheme httpScheme = new Scheme (HTTP_SCHEMA, 

PlainSocketFactory . getSocketFactory ( ) , HTTP_PORT) ; 
schemeRegistry . register (httpScheme) ; 
Scheme httpsScheme = new Scheme (HTTPS_SCHEMA, 

SSLSocketFactory . getSocketFactory ( ) , HTTPS_PORT) ; 
schemeRegistry . register (httpsScheme) ; 
ClientConnectionManager tsConnManager = 

new ThreadSaf eClientConnManager (httpParams, schemeRegistry); 
HttpClient tmpClient = new DefaultHttpClient (tsConnManager, httpParams); 
HttpConnectionParams . setSoTimeout (tmpClient . getParams ( ) , TIMEOUT) ; 
HttpConnectionParams . setConnectionTimeout (tmpClient . getParams ( ) , 

TIMEOUT) ; 
addUserAgent (tmpClient) ; 
return tmpClient; 

} 

private void addUserAgent (HttpClient client) { 

String userAgent = System . getProperty ( "http . agent " ) ; 
client . getParams ( ) . setParameter (CoreProtocolPNames . USER_AGENT , 
userAgent) ; 

} 
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Il codice è abbastanza esplicativo. L'unica domanda che il lettore si può tare riguarda l'opportunità 
dell'utilizzo diun'enwm invece che la classica implementazione del pattern GoF Singleton che utilizza 
una variabile statica e un metodo statico di Factory. 

NOTA 

Singleton è un pattern di creazione che permette non solo di avere un'unica istanza di un oggetto 
ma soprattutto di rendere questa istanza accessibile da un qualsiasi punto dell'applicazione. 

Anche se questo non avviene nella nostra applicazione, l'implementazione classica di un Singleton 
attraverso un attributo statico potrebbe non iùnzionare nel caso in cui l'oggetto venisse prima 
serializzato e poi deserializzato. In quel modo si riuscirebbe infatti a "rompere" il vincolo di unicità 
dell'istanza. Un' enum sappiamo invece che consente di descrivere le uniche possibili istanze di ima 
classe anche nel caso in cui queste venissero serializzate e quindi deserializzate. Se poi Yenum 
contiene un unico valore è facile comprendere come questo sia effettivamente w Singleton. 

NOTA 

Condizione necessaria ma non sufficiente affinché un oggetto sia seriaiizabie è che la relativa classe 
implementi l'omonima interfaccia. Se questo non avviene, le istanze corrispondenti non sono 
serializzabili. Per impedire la creazione di più istanze con lo stratagemma della 
serializzazione/deserializzazione è sufficiente rendere non serializzabile la nostra classe 

ThreadSafeHttpClientFactory. Qui abbiamo però avuto l'occasione di vedere qualcosa di diverso. 

Nel codice precedente abbiamo messo in evidenza la parte relativa all'impostazione del timeout, 
oltre che quella che permette di aggiungere alle richieste HTTP F informazione relativa allo user agent, 
che può essere molto utile per diversi motivi relativi alla gestione delle statistiche oppure a 
problematiche di sicurezza. 

Per ottenere il riferimento all'implementazione di Httpciient potremmo usare direttamente il 
metodo statico di Factory, ma in questo caso abbiamo deciso di creare anche un metodo statico della 

nostra Application: 

public class UghoApplication extends Application { 

public static HttpClient getThreadSaf eHttpClient ( ) { 

return ThreadSafeHttpClientFactory . INSTANCE . getThreadSaf eHttpClient ( ) ; 

} 

public static HttpClient getHttpClient ( ) { 
return new Def aultHttpClient ( ) ; 

} 

public static void releaseThreadSaf eHttpClient ( ) { 
ThreadSafeHttpClientFactory . INSTANCE . release ( ) ; 

} 

} 

In diversi punti dell'applicazione potremmo decidere di ottenere il riferimento all' Httpciient che 
può essere condiviso in modo sicuro tra più thread oppure se ottenerne uno "usa e getta". 

Per utilizzare questa implementazione della classe Application all'interno dell' applicazione il passo 
successivo consiste nella sua definizione nel file AndroidManif est . xml, nel seguente modo: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<manif est xmlns : android="http : / / schema s . android . com/ apk/ res/ android" 
package="uk . co .massimocarli . android. ugho" 
android : versionCode=" 1 " 
android: versionName=" 1 . 0 "> 

<uses-sdk android:minSdkVersion=" 7 " android : target Sdk Ver sion=" 1 6" /> 
<uses-permission android : name=" android . permission . INTERNET "/> 
Opplication 
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andr oid : name= " . UghoApplication " 

android: allowBackup="true" 
android : icon=" @drawable/ic_launcher " 
android: label=" @string/ app_name" 
android : theme=" @style/AppTheme"> 



</application> 
</manif est> 

ovvero attraverso l'attributo android :name dell'elemento <appiication/>, che conterrà come 
valore il nome della nostra implementazione. 

Nel caso volessimo usare questa implementazione di Httpciient sarebbe sufficiente sostituire la 
seguente riga di codice nel metodo ìogin < ) della classe Loginservice 

HttpClient httpClient = new Def aultHttpClient ( ) ; 

con questa 

HttpClient httpClient = UghoApplication . getThreadSaf eHttpClient () ; 

e il gioco è latto. 

Invio di una richiesta in POST 

Un aspetto molto importante di cui bisogna tenere conto in un'invocazione HTTP riguarda l'utilizzo 
di parametri Come sappiamo, nella modalità GET i parametri vengono appesi all'URI invocato e 
questo è in effetti quello che può avvenire nel caso precedente attraverso la connessione a un indirizzo 
del tipo: 

http : / / server : port /path/ resource?name=value&name2=value2 

Una soluzione nel caso del login è stata quella di eseguire FMD5 della password, ma questa non è 
una soluzione completamente efficiente in quanto permette di nascondere il valore iniziale ma non di 
effettuare un login rimandando al server la stessa richiesta. Sappiamo inoltre che questa modalità 
presenta alcuni svantaggi legati al fatto che si tratta di un'informazione con un limite nella lunghezza. 

Alcuni servizi, poi, non possono essere invocati se non in una modalità POST che consente, tra le 
altre cose, anche l'invio di file. In ottica REST sappiamo poi che il POST è associato a un'operazione 
di creazione, a differenza delPUT che viene associato alla operazione di update. Come dimostrazione 
dell'utilizzo del POST abbiamo implementato il servizio di registrazione. Come avvenuto per il login, il 
primo passo consiste nella definizione del protocollo di comunicazione con il server. Supponiamo di 
inviare un documento JSON così composto: 
{ 

"username" : "<username>" , 
"password" : "<md5>", 
"email" : "<email>", 
"birthDate" : birthdate_as_long, 
"location" : "<my location>" 

} 

per ottenere poi una risposta che può essere positiva (come il login) 

{ 

"result" : "OK", 
"username" : "<username>" , 
"email" : "<email>", 
"birthDate" : birthdate_as_long, 
"location" : "<my location>" 

} 

o di errore: 
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"result" : "KO", 

"message" : "messaggio di errore" 

} 

Il codice per l'invio e la gestione della richiesta in POST è contenuto all'interno del metodo 
reg ister o della classe RegistrationService. Come nel caso precedente, anche qui abbiamo 
aggiunto un parametro di tipo Context. 

NOTA 

Come nel caso del login, anche per la registrazione abbiamo creato un servizio dummy all'indirizzo 

http : / /www.massimocarli . eu/ android/ register .php, I I quale ritorna un valore OK nel caso in cui siano presenti 

tutti i campi e KOnel caso contrario. I campi di ritorno sono poi gli stessi inviati in input. 
Lasciando al lettore la visione del codice relativo all' AsyncTas k, nell'attività di registrazione 
vediamo solamente il codice di interesse in questo metodo register ( ) : 

public UserModel register (final Context context, final String username, 
final String password, final String email, final long birthDate, 
final String location) { 
UserModel userModel = nuli; 
JSONObject json = new JSONOb ject ( ) ; 
try { 

json.put ("username", username) ; 

j son . put ( "password" , MD5Utility .md5 (password) ) ; 
json . put ( "email" , email); 
json.put ("birthDate", birthDate) ; 
json.put ("location", location) ; 

final String registrationUrl = context . getResources ( ) 

.getString (R. string. register_url ) ; 
final HttpClient httpClient = UghoApplication 

. getThreadSafeHttpClient () ; 
final HttpPost request = new HttpPost (registrationUrl) ; 
reguest . setEntity (new StringEntity ( json . toString () ) ) ; 
reguest. addHeader ("Content-Type" , "application/ json") ; 
reguest . addHeader ( "Accept" , "application/ json" ) ; 

userModel = httpClient . execute (request, mUserModelResponseHandler) ; 
} catch ( JSONException e) { 
e . printStackTrace ( ) ; 

return UserModel . fromError ( "Error : " + e . getMessage ( ) ) ; 
} catch (UnsupportedEncodingException e) { 
e . printStackTrace ( ) ; 

return UserModel . fromError ( "Error : " + e . getMessage ()) ; 
} catch (ClientProtocolException e) { 
e . printStackTrace ( ) ; 

return UserModel . fromError ( "Error : " + e . getMessage ()) ; 
} catch (IOException e) { 
e . printStackTrace ( ) ; 

return UserModel . fromError ( "Error : " + e . getMessage ()) ; 

} 

return userModel; 

} 

Nel codice evidenziato vediamo come la differenza consista semplicemente nell' utilizzo di un 
oggetto di tipo HttpPost invece che HttpGet. Da notare anche la modalità con cui si imposta il 
contenuto della richiesta in POST, ovvero un documento JSON che impostiamo attraverso un 
oggetto di tipo StringEntity. Nel caso in cui si "parli JSON", è anche importante impostare il tipo 
con content-Type attraverso gli opportuni metodi di gestione degli header. Per il resto abbiamo 
mantenuto la stessa struttura dell'operazione di login, per cui il ResponseHandier è esattamente lo 
stesso. 

Concludiamo questo paragrafo con due considerazioni. La prima fa riferimento al caso in cui i 
parametri non venissero inviati attraverso un unico documento JSON o XML o di altro tipo bensì 
attraverso un insieme di parametri come quelli provenienti da un form In quel caso le istruzioni da 
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eseguire sarebbero queste: 

List<NameValuePair> postParameters = new ArrayLìst<NameValuePair> ( ) ; 
postParameters . add (new BasicNameValuePair ( "nome" , "valore" ) ) ; 
postParameters . add (new BasicNameValuePair ( "nome2 " , "valore2 " ) ) ; 
HttpEntity postEntity = new UrlEncodedFormEntity (postParameters) ; 

I parametri verrebbero impostati attraverso una specializzazione della classe HttpEntity che si 
chiama UrlEncodedFormEnt ity, che permette appunto l'invio di un insieme di informazioni nella 
modalità classica per un form I parametri vengono rappresentati da una lista di oggetti di tipo 
NameValuePa ir la cui unica implementazione disponibile è quella della classe BasicNameValuePair. 
Capiamo allora come l'invio di una richiesta in modalità POST non sia molto più complessa di quella 
relativa al caso GET. 

II secondo aspetto riguarda la possibilità di utilizzare delle richieste in POST per l'invio di 
informazioni più complesse come quelle relative a dei file di immagini o altro tipo di documenti. Qui 
Android non ha tutte le librerie necessarie, che quindi devono essere scaricate da alcuni progetti open 
source di Apache. In particolare servono le API della libreria HttpMime contenute negli 
HttpComponents (http://hc.apache.org/downioads.cgi), e in particolare quella che va sotto il 
nome à\Mime4J (http : // james . apache . org/downioad. cgi). Un esempio di codice per l'invio di 
un'immagine è il seguente: 

HttpClient httpClient = new Def aultHttpClient ( ) ; 
HttpPost request = new HttpPostO; 
URI targetUri = new URI (TARGET_URL) ; 
request . setURI (targetUri ) ; 

InputStream imagelS = getResources (). openRawResource (R. drawable . hamburger) ; 

InputStreamBody imagePart = new InputStreamBody (imagelS, "imageToUpload" ) ; 

MultipartEntity mpEntity = new MultipartEntity ( ) ; 

mpEntity . addPart ( "name" , new StringBody ( "value") ) ; 

mpEntity .addPart ("name2" , new StringBody ( "value2" )) ; 

mpEntity . addPart ( " imageToUpload" , imagePart ) ; 

request . setEntity (mpEntity) ; 

httpClient . execute (request , myResponseHandler ) ; 

Notiamo come sia stato possibile creare una specializzazione di HttpEntity descritta dalla classe 
MultipartEntity relativa a un contenuto multipari e come in esso sia stato possibile inserire le 
diverse Part. Nel caso di parametri di tipo string abbiamo utilizzato degli oggetti di tipo StringBody, 
mentre per il contenuto relativo al file abbiamo usato un oggetto di tipo InputStreamBody. Il resto del 
metodo è analogo a quello visto negli esempi precedenti 



Introduzione a Volley 

Data l'importanza dell'argomento era abbastanza strano che la piattaforma Android non mettesse a 
disposizione degli sviluppatori un framework che permettesse di rendere meno macchinosa la gestione 
del networking garantendo delle buone prestazioni Questo soprattutto alla luce della lunga diatriba 
suU'utilizzo dell' HttpClient diApache o delle HttpUrlConnection dichiarate bacate a turno nelle 
diverse release che si sono succedute. Probabilmente per questo motivo all'ultima Google IO (2013) 
è stato presentato un framework di nome Volley che vorrebbe proporsi come soluzione (o almeno ci 
prova). L'obiettivo di questo framework è infatti quello di gestire in modo trasparente tutta la gestione 
delle richieste attraverso un utilizzo ottimale di meccanismi di cache. Tra i benefici che dovrebbe 
portare abbiamo: 

• una programmazione automatica di tutte le richieste; 

• una gestione trasparente della cache in memoria e su disco; 
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• una buona gestione di ima delle cose più complesse da gestire, ovvero le interruzioni dei task; 

• un numero elevato di punti di estensione; 

• strumenti efficienti per il debug e il tracing. 

L'obiettivo di questo paragrafo è quello di fare una breve introduzione all'uso di questo framework 
attraverso qualche semplice esempio. 

La parte forse più complessa del framework è la sua installazione all'interno del nostro progetto in 
Android Studio. Iniziamo con l'eseguire il clone del progetto ingit nella cartella Aibraries del nostro 
progetto come avevamo fatto per la libreria ActionBarSherlock: 

git clone https : / / android. googlesource . com/platf orm/f rameworks /volley 

Il risultato è mostrato nella Figura 10.1, dove vediamo come il progetto disponga già di un file di 
configurazione per Gradle che però necessita di ima piccola modifica. 



ibraries 




► Ci ActionBarSherlock 
▼ C3 volley 

► D build 

► Dsrc 

► C]tests 

0 .classpath 
0 .gitignore 
0 .project 
0 Android.mk 
<> Android Manifestami 
0 build. gradle 
B build. xml 
B custom_rules.xml 
0 proguard.cfg 
0 proguard-project.txt 
ili project.properties 
31 volley.iml 
► QUCHO [UCHO-UCHO] 



Figura 10.1 Struttura a directory dopo il clone del progetto volley. 



NOTA 

Android Studio è in continua evoluzione, per cui potrebbero essere richieste altre modifiche ai file di 
Gradle nelle successive versioni del tool. Per questo motivo, in caso di problemi nel build, si 
rimanda alla documentazione ufficiale. 
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Andiamo allora a modificare il file settings . gradie nella root della gerarchia dei file associati al 
nostro progetto UGHO aggiungendo quello che abbiamo evidenziato di seguito: 

include ' :UGHO' , ' : libraries : ActionBarSherlock ' , ' : libraries : volley ' 

Si tratta del riferimento alla libreria contenuta nella cartella volley. Il file buiid. gradie relativo al 
progetto UGHO (UGHO-UGHO) diventa questo: 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/maven2' } 

} 

dependencies { 

classpath ' com . andrò id .tools.build:gradle:0.5.+' 

} 

} 

apply plugin: 'android' 

dependencies { 

compile project ( ' : libraries : ActionBarSherlock ' ) 
compile prò ject ( ' : libraries : volley ' ) 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdk Ver sion 8 

targetSdkVersion 16 
} 

} 

Vediamo come sia stata aggiunta la dipendenza con il progetto appena aggiunto. Infine, lo stesso 
progetto volley, avrà un file di configurazione build. gradle fatto nel seguente modo: 

buildscript { 

repositories { 

maven { uri ' http : / / repol . maven . org/ maven2 ' } 

} 

dependencies { 

classpath ' com . android . tools . build : gradle : 0 . 5 . + ' 

} 

} 

apply plugin: ' android-library ' 

android { 

compileSdkVersion 17 
buildToolsVersion = 17 

sourceSets { 

defaultConfig { 

testPackageName ' com . android . volley . tests ' 

} 

main { 

assets . srcDirs = ['assets'] 

res.srcDìrs = [ ' res ' ] 

aidl.srcDirs = ['src'] 

resources . srcDirs = ['src'] 

renderscript . srcDirs = ['src'] 

java. srcDirs = ['src'] 

manif est . srcFile ' AndroidManif est . xml ' 

} 

instrumentTest { 

assets . srcDirs = ["tests/assets"] 
res. srcDirs = ["tests/res" ] 
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resources . srcDirs = [ "tests/src" ] 
java.srcDirs = ["tests/src"] 

} 

} 

} 

La prima parte evidenziata è quella che, rispetto a quando è stato scaricato con il clone, abbiamo 
aggiunto noi e che definisce sostanzialmente la posizione dei repository e della libreria da cui il 
progetto dipende. Da notare infine come siano state configurate le diverse directory del progetto 
(comprese quelle per lo unit test) alla luce del tatto che si trattava di un progetto per eclipse. Una 
modifica molto importante è invece relativa alla versione supportata: framework Volley vuole infatti 
una versione di API Level 8. Questo ci costringe ad aumentare anche il nostro API Level minimo. 

A questo punto dovremmo riuscire a utilizzare le classi di questo framework all'interno del nostro 
progetto. Come dimostrazione implementiamo il servizio di login in alternativa a quanto fatto in 
precedenza con Httpciient. I concetti principali alla base di questo framework sono due: 

• RequestQueue; 

• Request. 

Quando abbiamo l'esigenza di eseguire una richiesta HTTP dovremo sostanzialmente creare una 
coda e inviare su di essa una richiesta che potrà essere GET, POST e così via. La coda potrà essere 
creata al volo oppure inizializzata una sola volta e quindi riutilizzata in diversi punti dell'applicazione 
attraverso la solita implementazione del pattern Singleton. Come vedremo questo approccio 
permette di semplificare notevolmente F architettura dell'applicazione nel caso in cui lo si utilizzi in 
alternativa all'oggetto Asyndask. A tal proposito abbiamo realizzato la classe voiieyLoginActivity, 
di cui riportiamo le parti di interesse: 

final RequestQueue requestQueue = Volley . newRequestQueue (this) ; 

final String loginUrl = getResources ( ) . getString (R. string . login_url, 

username, MD5Utility .md5 (password) ) ; 
JsonObjectRequest jsOb jRequest = new JsonObjectRequest (Request .Method. GET, 
loginUrl, nuli, new Response . Listener<JSONOb ject> ( ) { 

@Override 

public void onResponse ( JSONOb ject response) { 

mProgressAlertDialog . dismiss () ; 
UserModel userModel = nuli; 

final String result = response . optString ( "result " , KO_RESULT) ; 
if (KO_RESULT.equals (result) ) { 

userModel = UserModel . f romError (response . optString ( "message" ) ) ; 
} else { 

final long birthDate = response . optLong ( "birthDate" , 0); 

if (birthDate > 0) { 

userModel = UserModel . create (birthDate) 

. withEmail (response . optString ( "email" ) ) 

. withUsername (response . optString ( "username" ) ) 

.withLocation (response . optString ( "location" ) ) ; 

} else { 

userModel = UserModel 

. f romError ( "Error in birthDate data!"); 

} 

} 

if (userModel != nuli && ! userModel . hasError () ) { 

Intent resultlntent = new Intento ; 

result Intent . putExt ra (USER_DATA_EXTRA, userModel) ; 

setResult (RESULT_OK, resultlntent) ; 

finish ( ) ; 
} else { 

mErrorTextView . setText (userModel . getErrorMessage () ) ; 
mErrorTextView . setvisibility (View.VISIBLE) ; 

} 
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} 

} , new Response . ErrorListener ( ) { 

@Override 

public void onErrorResponse (VolleyError error) { 
mErrorTextView . setText (error . toString ( ) ) ; 
mErrorTextView. setVisibility (View. VISIBLE) ; 

} 

}) ; 

mProgressAlertDialog = new ProgressAlertDialog ( ) ; 
mProgressAlertDialog . show (getSupportFragmentManager ( ) , 

PROGRE S S_D I ALOG_TAG ) ; 
requestQueue . add ( jsObjRequest) ; 

La logica dietro a questo framework è molto semplice. Inizialmente abbiamo inizializzato la coda 
delle richieste attraverso il codice 

final RequestQueue requestQueue = Volley . newRequestQueue (thìs ) ; 

dopodiché abbiamo creato un'istanza di una particolare specializzazione della classe Request, di 
tipo jsonObjectRequest, che si aspetta una rispo sta di tipo JSON di cui esegue ilparsingin 
automatico ritornando direttamente un oggetto di tipo jsoNOb ject. In caso di errore viene invece 
invocato il metodo dicallback relativo all'implementazione dell' interfaccia Response . ErrorListener. 
I metodi di callback vengono eseguiti all'interno del thread principale per cui è possibile implementare 
direttamente le operazioni per la visualizzazione e gestione dei risultati oppure per la visualizzazione 
dei messaggi di errore. 

Conclusioni 

In questo capitolo abbiamo affrontato due argomenti molto importanti per i dispositivi di ultima 
generazione. Nella prima parte abbiamo descritto quello che è il modello di sicurezza diAndroid e in 
particolare abbiamo approfondito la gestione dei permessi. Abbiamo visto qualè F importanza di 
questo meccanismo fornendo delle linee guida per la protezione dei componenti principali come 
activity e content provider. Nella seconda parte abbiamo invece visto come interagire con server 
esterni attraverso il protocollo HTTP sfruttando le librerie Httpciient di Apache. Abbiamo creato 
esempi sia per l'invio di richieste nella modalità GET sia nella modalità POST, con un accenno al caso 
multipari. Abbiamo concluso con la descrizione del framework Volley per la gestione delle richieste 
HTTP all'interno di una coda. 



462 



Capitolo 11 



Gestione delle animazioni 



Nei Capitoli 5 e 6 abbiamo approfondito alcuni componenti fondamentali nella creazione delle 
interfacce grafiche delle nostre applicazioni. Ci siamo infatti occupati di view, viewGroup (layout) e 
Listview. Abbiamo visto come utilizzare temi e stili per rendere questi componenti più accattivanti 
attraverso un approccio dichiarativo. In questo capitolo ci occupiamo invece di un altro aspetto 
fondamentale, ovvero le animazioni In particolare descriveremo quello che è il framework introdotto 
conHoneycomb (Android 3.0), il quale ci permette di animare un qualunque oggetto, visibile o meno, 
rendendo ancora più interattive le nostre applicazioni 

Animazione di proprietà 

Dalla versione 3.0 della piattaforma è stato introdotto un nuovo framework per la gestione delle 
animazioni il cui obiettivo è quello di colmare alcune lacune del precedente, che comunque continua a 
essere supportato perché molto più semplice da utilizzare e configurare. Le nuove API permettono di 
modificare, secondo determinate regole, il valore di alcune proprietà di un oggetto qualunque; API 
precedenti per le animazioni sono invece dedicate esclusivamente alle view e valgono solo per alcune 
delle proprietà. Un esempio citato nella documentazione riguarda per esempio l'impossibilità di 
modificare nel tempo il colore di sfondo di una Textview a differenza della sua posizione o 
dimensione. Un altro problema delle vecchie API è relativo alla gestione degli eventi che non è 
sempre allineata con il posizionamento del componente a cui gli stessi fanno riferimento. Questo 
significa, per esempio, che se un pulsante si muove, lo stesso non succede per l'area sensibile alla sua 
selezione. 

Come funzionano 

Abbiamo detto che il nuovo framework consente di modificare nel tempo il valore di un qualunque 
insieme di proprietà di un qualunque oggetto. 
NOTA 

Come accennato, il "nuovo" framework è stato introdotto per permettere lo sfruttamento di tutte le 
potenzialità hardware dei nuovi smartphone ma soprattutto dei tablet. Questo non significa che 
debbano essere necessariamente utilizzate: se le API precedenti permettono l'implementazione di 
quanto voluto, sono sicuramente da preferire per la loro semplicità d'uso e per la minore quantità di 
codice richiesto. 

Oltre alla ovvia definizione di quali siano queste proprietà, le API permettono l'impostazione delle 
seguenti caratteristiche di un'animazione: 

• durata; 

• distribuzione nel tempo (time interpolation); 

• eventuali ripetizioni (repeat count); 

• composizioni di animazioni diverse (animator set); 
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• frequenza di visualizzazione (fraine refresh delay); 

La prima informazione è molto importante in quanto consente di specificare la durata 
dell'animazione, che di default è di 300 ms. Supponiamo ora di voler animare lo spostamento di ima 
view da un punto A dello schermo a un punto B. È evidente che i soli punti A e B non sono sufficienti 
a descrivere l'animazione. Innanzitutto l'oggetto può andare da A a B per la strada più corta, ovvero 
sul segmento che li unisce, ma potrebbe anche prima allontanarsi, quindi ruotarci attorno e arrivare a 
B con un moto a spirale. Anche disponendo del tragitto seguito non avremmo completamente 
caratterizzato l'animazione, poiché l'oggetto si potrebbe muovere velocemente all'inizio e poi 
rallentare, oppure fare l'inverso, o semplicemente muoversi con velocità costante. E ovvio che, a 
parità di percorso, l'oggetto si muoverà tanto più velocemente quanto minore sarà la durata 
dell'animazione. L'informazione che associa la posizione dell'oggetto nel percorso al particolare 
istante rappresenta quella che abbiamo chiamato time interpolation. Vedremo la disponibilità di 
diverse modalità di interpolazione ma soprattutto la possibilità di aggiungerne di personalizzate. 

NOTA 

Il fatto di delegare a un oggetto estemo l'implementazione di un particolare algoritmo sta alla base 
del design pattern GoF chiamato Strategy. In questo modo la particolare animazione non è legata 
ad alcuna regola di interpolazione ma solamente al fatto che tale regola esista. Fornendo all'oggetto 
responsabile dell'animazione diverse implementazioni dello Strategy, otterremo differenti modalità di 
interpolazione. È lo stesso pattern che si utilizza in Java standard per gestire diversi layout di uno 
stesso container. 

Dopo un periodo pari alla sua durata, ranimazione termina. Come succede in tutti i framework di 
questo tipo, è comunque possibile non solo specificare il numero di volte che l'animazione dovrà 
essere ripetuta ma anche se questo dovrà essere fatto in senso inverso. Si può quindi decidere quante 
volte un oggetto potrà andare da A a B e se dovrà anche andare da B ad A. Spesso le animazioni più 
interessanti si ottengono dalla composizione di altre esistenti Pensiamo, per esempio, al caso 
precedente dell'oggetto che si muove dal punto A al punto B e contemporaneamente ruota su se 
stesso. Attraverso wanimation set sarà possibile comporre l'effetto di più animazioni. Va poi 
considerato un aspetto molto importante relativo alla frequenza con cui le modifiche sull'oggetto 
animato vengono rappresentate graficamente nella situazione in cui questo avesse senso (oggetti 
visibili). Anche qui esiste un valore di default di 10 ms, il quale viene preso come riferimento in quanto 
l'effettiva frequenza di aggiornamento dipenderà dallo stato del dispositivo. 

Quanto descritto può essere riassunto nel diagramma delle classi mostrato nella Figura 11.1, che ci 
permette di identificare i vari componenti in gioco e come questi collaborano tra loro. 
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AccelerateDeceleratelnterpolator 




«interface» 






\<j Timelnterpolator 




<3- 


Operations 






+ getlnterpolation( input : float ) 
^ \> ^ ^ 


: float 





j Lineari nterpolator 



OverShootlnterpolator 



Deceleratelnterpolator 



__i Acceleratelnterpolator 



Cyclelnterpolator 



. Bouncelnterpolator 



AnticipateOvershootlnterpolator 



_J Anticipatelnterpolator 



«interface» 
TypeEvaluator 



Operations 

+ evaluate( fraction : float, startValue : Object, endValue : Object ) : Object 



ArgbEvaluator 



«o- — 



^7 _ 



LI IntEvaluator 



~ - LJFIoatEvaluator 



Figura 11.1 Diagramma delle classi del framework Property Animator. 

Si tratta di classi contenute nei package android.animation e android.view.animation. Come 
possiamo notare, alla base di tutto vi è la classe astratta Animator, che contiene la descrizione di tutte 
le caratteristiche comuni alle animazioni, ovvero che possono essere avviate e infine terminate. In 
questa classe, anche se non rappresentato nel diagramma, vengono inoltre gestiti gli eventi attraverso 
l'interfaccia Animator .AnimatorListener. È un modo per essere avvisati dell'inizio, della fine, della 
ripetizione o dell'annullamento di un'animazione. È spesso utile, per esempio, quando si deve 
attendere il termine di un'animazione per eseguire alcune operazioni. 

NOTA 

Come spesso accade quando si utilizzano interfacce con diverse operazioni, i framework forniscono 
anche delle classi, denominate adapter, che implementano tutti i metodi dell'interfaccia con corpo 
vuoto. In questo modo si possono creare delle specializzazioni degli adapter che eseguono 
\'overridede\ soli metodi di interesse e non di tutti quelli previsti dall'interfaccia. Non sono da 
confondere con quelli che abbiamo visto nella gestione delle ListVìew. 

La classe vaiueAnimator è la prima realizzazione di Animator che permette di gestire il valore di 
una proprietà di un oggetto di riferimento (definito target) da un valore iniziale a un valore finale, 
specificati entrambi al momento della sua creazione. 

NOTA 

Sebbene il tutto risulterà chiaro successivamente, diciamo subito che il vaiueAnimator non è 

responsabile della modifica effettiva della proprietà dell'oggetto target ma solamente del calcolo del 
valore corrispondente. 

Esso contiene anche le informazioni relative alle grandezze specificate in precedenza come la 
durata, le eventuali ripetizioni e così via. Si tratta della classe che ha la responsabilità del timing, 
ovvero della scansione degli istanti in cui calcolare i vari ffame dell'animazione. Essa infatti, in base al 
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tempo totale e a quello trascorso, calcola, attraverso il tì raelnterpolator impostato, un valore che si 
chiama fraction e che è appunto la frazione di animazione corrispondente al tempo passato. Se 
osserviamo l'interfaccia tì me Interpolai: or, notiamo come definisce l'operazione 

public abstract float getlnterpolation ( f loat input) 

il cui valore di input è un f ioat che vale 0.0F nell'istante iniziale e 1 .OF in quello finale 
dell'animazione. Chiariamo con un esempio prendendo come riferimento il li nearlnterpolator, li 
quale calcola la frazione dell'animazione in un modo molto semplice. Se 0.0F è il valore di input 
corrispondente all'istante iniziale, e se 1.0F è quello relativo all'istante finale, è ovvio che la frazione di 
animazione corrispondente all'input i con 0.0 < i< 1.0 è esattamente i. 

Se duration rappresenta la durata dell'animazione (per esempio 300 ms di defàult) e se 
indichiamo con rate il tempo di aggiornamento (che di default è 10 ms), l'oggetto fraiueAnimator 
interrogherà il Timeinterpoiator un numero di volte dato da 

numero invocazioni = duration/rate 

passando un valore di input corrispondente a 

input = n*rate/duration 

dove n è l'invocazione ennesima. Infatti con n = 0 otteniamo un input pari a 0.0F, mentre con n = 
duration/rate otteniamo un input pari a 1.0F. 
NOTA 

A coloro che non sono esperti di Java facciamo notare come un valore letterale pari a 0.0 in Java 
non sia considerato come noat ma come doublé. Il corrispondente valore di tipo fioat si ottiene 
appendendo una F. Completiamo l'osservazione dicendo che questi caratteri possono anche essere 
minuscoli, ma la cosa è sconsigliata in quanto potrebbero portare a codice poco leggibile, come 
quello che si avrebbe specificando un valore di tipo long nel modo 101 (confondibile con 101) 
piuttosto che 10L. 

Abbiamo quindi capito che l'oggetto vaiueAnimator si occupa del timing e chiede al 
Timelnterpolator a che punto si è nell'animazione in un particolare istante. E bene ricordare che il 
Timelnterpolator di default non è il Linearinterpoiator ma quello descritto dalla classe 
AcceierateDeceierateinterpoiator, che consente di avere animazioni accelerate all'inizio che poi 
rallentano verso la conclusione. 

È un'impostazione che può essere cambiata con implementazioni personalizzate attraverso il 
metodo 

public void setlnterpolator (Timelnterpolator value) 

Abbiamo visto che il particolare Timelnterpolator risponde alla domanda "a che punto siamo?" 
ma serve anche un modo per calcolare il corrispondente valore della proprietà che possiamo definire 
come "animata". Questo è il compito delle implementazioni dei TypeEvaiuator, i quali, come 
possiamo vedere dal diagramma precedente, implementano la seguente operazione: 

public abstract Object evaluate (float fraction, Object startValue, Object endValue) 

che permette di ottenere un valore di ritomo della proprietà corrispondente al valore della frazione 
e ai valori iniziali e finali 
NOTA 

Un' osservazione che possiamo fare relativamente all'interfaccia T YP eEvaiuator è che non è generica, 
ovvero che non è del tipo TypeEvaluator<T>. Probabilmente questo è dovuto al fatto che il tipo di ritorno 
e quello dei valori iniziale e finale dell'animazione possono essere anche diversi tra loro. 

Nel caso in cui si trattasse, per esempio, di una proprietà di tipo int con valore iniziale 0 e valore 
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finale 100, l'implementazione di TypeEvaiuator descritta dalla classe intEvaiuator non fera altro che 
implementare l'operazione evaiuate ( ) in un modo che probabilmente sarà del tipo: 

public Object evaiuate (float fractìon, Object startValue, Object endValue) { 
int startValuelnt = (Integer) startValue; 
int endValuelnt = (Integer) endValue; 

int evaluatedValue = startValueInt+ (endValuelnt-startValuelnt ) *f raction; 
return evaluatedValue; 

} 

Notiamo infatti come un valore di f raction di 0.0F permetta di ottenere start vaiue, mentre un 
valore di f raction pari a 1 .0F permetta di ottenere endvaiue. 
NOTA 

Nel codice precedente è stata utilizzata più di qualche volta la conversione implicita tra oggetti 
wrapper e corrispondenti valori primitivi. Si tratta di una feature del compilatore di Java introdotta con 
la versione 1.5. 

A questo punto possiamo impostare il particolare TypeEvaiuator Sul nostro ValueAnimator 

attraverso questo metodo: 

public void setEvaluator (TypeEvaiuator value) 

Un framework che si rispetti deve comunque fornire allo sviluppatore alcuni strumenti che ne 
semplifichino l'utilizzo nei casi più frequenti Questo è il motivo per cui la classe ValueAnimator 
dispone di diversi metodi statici di Factory che permettono di ottenere direttamente il riferimento alle 
sue istanze più comuni Per esempio, attraverso il metodo 

public static ValueAnimator ofFloat (float .. . values) 

si può ottenere il riferimento a un ValueAnimator che permette di gestire l'animazione di una 
proprietà di tipo f ioat tra un insieme di valori specificati attraverso un vararg dello stesso tipo. Per la 
verifica del funzionamento di queste animazioni abbiamo realizzato un'applicazione che si chiama 
AnimationTest, la quale dovrà avere un API Level minimo paria 12, ovvero quello diHoneycomb. 
Le API che utilizzeremo non esistono infetti nelle versioni precedenti della piattaforma, e tale lacuna 
non è compensata dalla Compatibility Library. 

NOTA 

Il fatto che si tratti di API che hanno l'obiettivo di sfruttare appieno le caratteristiche hardware di vari 
dispositivi rende l'ultima affermazione piuttosto ovvia. 

Il primo esempio contenuto nell'applicazione è stato implementato in un fragment che si chiama 
ValueAnimatorFragment, che contiene la logica di modifica di un valore di tipo intero attraverso un 
oggetto di tipo ValueAnimator. L'interfaccia è molto semplice e contiene, come possiamo vedere 
nella Figura 11.2, due componenti di tipo seekBar che permettono di scegliere il numero finale a cui 
contare oltre che la durata entro cui il conteggio dovrà avvenire. 
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Figura 11.2 Esempio di ValueAnimator in esecuzione. 

Lasciando al lettore la visione del codice relativo alla gestione della UL ci dedichiamo alla parte 
specifica dell'animazione, che riportiamo di seguito: 

private void startAnimation ( final TextView output, 

final int endValue, final long duration) { 
ìf (mRunning . get ( ) ) { 
return; 

} 

ValueAnimator valueAnimator = ValueAnimator . of Int (0, endValue); 
valueAnimator . setDuration (duration) ; 
valueAnimator . addUpdateListener ( 

new ValueAnimator . AnimatorUpdateListener () { 

@Override 

public void onAnimationUpdate (ValueAnimator animation) { 

String value = animation. getAnimatedValue () .toStringO ; 
output . setText (value) ; 

} 

}); 

valueAnimator . addListener (new Animator . AnimatorListener () { 

@Override 

public void onAnimationCancel (Animator animator) { 

Toast .makeText (getActivìty ( ) , "onAnimationCancel", 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

SOverride 

public void onAnimationEnd (Animator animator) { 
mRunning. set (false) ; 

Toast .makeText (getActivity ( ) , "onAnimationEnd", 
Toast . LENGTH_SHORT) . show ( ) ; 
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} 

SOverride 

public void onAnimationRepeat (Animator animator) { 

Toast .makeText (getActivìty ( ) , "onAnimationRepeat", 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

@Override 

public void onAnimationStart (Animator animator) { 

Toast .makeText (getActivity ( ) , "onAnimationStart", 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

}) ; 

mRunning . set (true) ; 
valueAnimator . start ( ) ; 

} 

All'interno del metodo startAnimation ( ) abbiamo come prima cosa creato il nostro 
valueAnimator per le variabili di tip o intero come segue: 

ValueAnimator valueAnimator = ValueAnimator . oflnt ( 0 , endValue) ; 

Attraverso il metodo statico di Factory of int ( ) abbiamo ottenuto il riferimento a un 
ValueAnimator relativo all'animazione di una qualunque proprietà di tipo int tra due valori che 
passiamo come parametri Finora abbiamo parlato di animazioni di proprietà ma non di come i 
corrispondenti valori possano essere utilizzati A tale scopo esistono due opzioni 

• implementare l'interfaccia ValueAnimator . AnimatorUpdateListenerj 

• Utilizzare la Classe Ob jectAnimator. 

In questo esempio abbiamo utilizzato il primo meccanismo, mentre il secondo lo vedremo 
successivamente. Per utilizzare il valore di una proprietà animata sarà sufficiente registrarsi come 
listener di tipo ValueAnimator . AnimatorUpdateListener COme fatto attraverso il frammento di codice 
evidenziato in precedenza. Nello specifico non abbiamo fatto altro che modificare il valore della 

TextView di Output. 

Nel nostro esempio vogliamo fare in modo che l'animazione non venga avviata più volte, per cui 
abbiamo definito una variabile di tipo AtomicBoolean di nome mRunning che viene messa a true 
quando l'animazione parte e poi a false nel momento in cui l'animazione termina. Per farlo abbiamo 
semplicemente utilizzato un'implementazione dell'interfaccia Animator . AnimatorListener riportando 
a false il valore della variabile mRunning. Le altre istruzioni sono ormai ovvie e permettono di 
impostare la durata dell'animazione e avviarla. 

NOTA 

Anche alla luce di quanto visto nel Capitolo 9, è importante sottolineare come la notifica attraverso 
l'interfaccia Animator. AnimatorListener avvenga all'interno del ThreadUI, ovvero dell'unico responsabile 
della gestione dell'interfaccia grafica. In caso contrario il codice precedente avrebbe dato un errore 
in esecuzione. 

Eseguendo l'applicazione, il lettore potrà notare la visualizzazione dei valori di tipo int nella parte 
centrale. Essi andranno dal valore iniziale a quello finale distribuiti nel tempo impostato come durata. 
Lasciamo al lettore la modifica del codice per l'utilizzo di altre specializzazioni di Timelnterpolator e 

di TypeEvaluator. 

La classe ObjectAnimator 

La classe valueAnimator consente l'interpolazione nel tempo di alcuni valori che è poi possibile 
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usare attraverso l'interfaccia Animator . AnimatorListener. Nel caso in cui si volessero utilizzare tali 
valori per la modifica di una proprietà di un oggetto, il framework ci offre la classe Obj e et Animator, 
la quale eseguirà per noi l'intero lavoro con una limitazione. Affinché Fob jectAnimator, che 
specializza la classe vaiueAnimator, possa modificare il valore di una proprietà di un oggetto target, è 
necessario che lo stesso ne permetta l'accesso attraverso un corrispondente metodo set che segua le 
classiche regole di carnei notation descritte dalle specifiche JavaBean. Per esempio, per poter 
modificare il valore della proprietà myProp un oggetto dovrà disporre del metodo setMyProp. Nel 
caso in cui l'oggetto non avesse tale metodo o comunque lo stesso non seguisse tale convenzione, si 
può comunque implementare il pattern Adapter (sì, sempre lui) e quindi wrappare l'oggetto 
all'interno di un altro che esponga le operazioni volute all' Ob jectAnimator adattandole all'interfaccia 
disponibile, come possiamo vedere nel diagramma nella Figura 11.3. 



=lAnimatedObject 

Qperations 
+ myMethod( ) : void 



~ b, 

animatedObject.myMethodO 



Figura 11.3 Utilizzo dell'AnimatorAdapter. 

Come ultima opzione è sempre possibile l'utilizzo della classe vaiueAnimator come descritto nel 
paragrafo precedente: 

Anche la classe objectAnimator dispone di alcuni metodi di Factory che questa volta sono deltipo 

public static ObjectAnimator oflnt (Object target, String propertyName, int . . . values) 

dove notiamo, insieme ai valori dell'animazione, la presenza dell'oggetto target e il nome della 
proprietà da animare. L'ultimo parametro è di tipo varargs e descrive, come nel caso precedente, i 
valori per il calcolo dell'animazione. Nel caso in cui si specificasse un unico valore esso verrà 
considerato come quello finale, mentre il valore iniziale dovrà essere dedotto dall'oggetto target 
attraverso un metodo del tipo get. Se la proprietà si chiama myProp e si specifica per vaiues un unico 
valore, l'oggetto target dovrà disporre del metodo getMyProp ( ) , che verrà utilizzato per la definizione 
del valore iniziale. Anche questa può essere vista, se vogliamo, come una limitazione a cui si può 
porre rimedio attraverso il pattern Adapter visto in precedenza. Come ultima considerazione 
relativamente alla classe objectAnimator c'è sempre la possibilità di essere avvisati di un 
aggiornamento attraverso l'interfaccia VaiueAnimator . AnimatorUpdateListener, al fine di invalidare 
eventuali view nel caso si agisse su proprietà che già non assolvono a tale operazione. 

Animazioni composte con la classe AnimatorSet 

Come già accennato, è possibile creare delle animazioni attraverso la composizione di animazioni 




1 AnimatorAdapter 

Attributes 



Operations 
+ setProp( ) : void 
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esistenti. Non serve che tutte le animazioni abbiamo la stessa durata o siano avviate tutte nello stesso 
momento: la classe AnimatorSet ci mette a disposizione una serie di operazioni che permettono 
l'esecuzione di animazioni secondo diversi criteri Una modalità di utilizzo della classe AnimatorSet 
prevede Fuso dei metodi 

public void playTogether (Collection<Animator> items) 
public void playSequentially (List<Animator> items) 

che permettono l'aggiunta di animazioni da eseguire insieme o sequenzialmente. Di questi metodi 
esiste anche la versione con parametri di tipo varargs. 

Nei metodi precedenti il parametro del metodo playTogether ( ) è una collection, a differenza di 
quello del metodo playSequentially ( ) che è una List. Questo è dovuto al fatto che, mentre una 
List è ordered (gli elementi sono in sequenza), una collection generica potrebbe non essere tale, 
come succede per esempio per i set. 

Una seconda modalità di composizione di più Animator prevede invece l'utilizzo della classe 
AnimatorSet . Builder che implementa appunto il design pattern Builder della GoF. Attraverso il 
seguente metodo 

public AnimatorSet . Builder play (Animator anim) 

si ottiene il riferimento al Builder, il quale contiene una serie di metodi per descrivere l'animazione 
complessiva come insieme di altre in un modo molto più semplice e intuitivo. Un esempio potrebbe 
essere il seguente: 

AnimatorSet s = new AnimatorSet () ; 
s . play (animi ) . with (anim2 ) ; 
s . play (anim3 ) . after (animi ) ; 
s . play (anim4 ) . bef ore (anim2 ) ; 

il quale permette non solo di comporre l'animazione complessiva ma di specificare anche, 
attraverso i metodi with ( ) , after ( ) e bef ore ( ) , le relazioni tra esse. 

Definizione dichiarativa delle animazioni 

Finora abbiamo descritto le animazioni attraverso delle righe di codice ma è possibile definire gli 
stessi oggetti attraverso dei documenti XML che ora vengono gestiti come risorse nella cartella 
/res/animator. Dalla versione 3.1 della piattaforma le animazioni che descriveremo di seguito e che 
definiremo legacy potranno comunque essere definite anch'esse nella cartella /res/animator e non più 
h/res/anim, anche perché è possibile, in questo modo, avere una preview attraverso gli strumenti 
dell' ADT. Per ognuna delle classi che abbiamo visto esiste un corrispondente elemento XML e in 

particolare <animator> per le ValueAnimator, <ob jectAnimator/> per le Ob jectAnimator e <set> 

per le AnimatorSet. Per spiegare questa modalità di descrizione delle animazioni abbiamo realizzato 
un altro esempio che permette la visualizzazione di un cuore pulsante al centro del display. Oltre alla 
definizione dichiarativa di Un Ob jectAnimator, l'esempio ci consente di verificare l'utilizzo di un 
adapter. L'animazione è molto semplice e descritta dal file beatìng.xmi contenuto nella cartella 
/res/animator. 

<?xml version="l . 0" encoding="utf-8 " ?> 

<set xmlns : android="http : / / schemas . androìd . com/ apk/res/android" 
android: ordering="together "> 
<ob jectAnimator 

androìd: ìnterpolator=" @ androìd : anim/ accelerate_interpolator " 
android :duration=" 800" 
android : propertyName= " size " 

android: repeatMode="reverse" 
android: repeatCount=" infinite" 
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andrò id : valueFrom= "400" 
android: valueTo=" 600 " 
android : valueType="intType"> 
</ob jectAnimator> 
</set> 

È un file di facile comprensione. Rileviamo solamente la presenza di un elemento <set/> nonostante 
vi sia un unico <ob jectAnimator />. Questo solo per consentire al lettore di aggiungere altre 
animazioni per testarne il funzionamento. Il frammento di codice evidenziato riguarda il nome della 
proprietà animata, che nel nostro caso è size. L'oggetto che abbiamo inserito nel layout 

fragment_object_animator .xml è Comunque un'lmageView che non dispone delmetodo setSize () , 

per cui si richiede l'utilizzo di un adapter che abbiamo descritto attraverso la classe 

ImageViewSizeAdapter: 
public class ImageViewSizeAdapter { 

private View mAdaptee; 

public ImageViewSizeAdapter (View adaptee) { 
this .mAdaptee = adaptee; 

} 

public void setSize (int size) { 

LayoutParams layoutParams = new LayoutParams (size, size) ; 
layoutParams . gravity = Gravity . CENTER; 
mAdaptee . setLayoutParams (layoutParams) ; 

} 

} 

In riferimento alla imageview viene passato attraverso il costruttore e nell'implementazione del 
metodo setsize o si provvede al suo ridimensionamento attraverso un oggetto di tipo 
LinearLayout . LayoutParams. A questo punto non ci resta che descrivere il codice che abbiamo 

inserito nel met od onCreateView() del fragment Ob jectAnimatorFragment: 
public class Ob jectAnimatorFragment extends Fragment { 

private AnìmatorSet mAnimatorSet; 

@Override 

public View onCreateView (Layoutlnf later inflater, 

ViewGroup container, Bundle savedlnstanceState) { 
final View view = inflater . inf late (R . layout . fragment_object_animator, 
nuli) ; 

ImageView heartView = (ImageView) view. find.ViewById(R. id.heart_image) ; 
ImageViewSizeAdapter adapter = new ImageViewSizeAdapter (heartView) ; 
mAnimatorSet = (AnimatorSet) Animatorlnf later . 

IoadAnimator (getActivity ( ) , R . animator . beating) ; 
mAnimatorSet . setTarget (adapter) ; 
return view; 

} 

SOverride 

public void onStartO { 
super . onStart ( ) ; 
mAnimatorSet . start ( ) ; 

} 

} 

Dopo aver creato un'istanza di ImageViewSizeAdapter abbiamo ottenuto il riferimento 
all'animazione descritta dalla risorsa precedente attraverso il metodo statico IoadAnimator o della 
classe Animatonnf later. Successivamente abbiamo impostato l'adapter come target 
dell'animazione, che abbiamo avviato ottenendo il cuore pulsante mostrato nella Figura 11.4. 
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Figura 11.4 Esempio di ObjectAnimator in azione. 



Attraverso questo pattern abbiamo quindi capito come sia in effetti possibile "animare" una 
qualunque proprietà di un qualunque oggetto. Non tutte le proprietà si mappano necessariamente in 
qualcosa di visibile, ma questo è l'utilizzo principale. 

Animazioni (legacy) 

In questo paragrafo descriviamo le animazioni che sono legacy, cioè ancora esistenti nella nuova 
piattaforma nonostante il nuovo framework introdotto in Honeycomb e descritto nel paragrafo 
precedente. Per "animazione" si intende una qualunque modifica nel tempo, colore, posizione, 
dimensione e orientamento di un componente nel display. Intuitivamente possiamo realizzare un 
qualunque tipo di animazione in due modi diversi II primo è quello tipico del "vecchio" cinema, il 
quale consente di sfruttare le capacità di interpolazione dell'occhio umano per creare animazioni a 
partire da una successione di immagini che vengono riprodotte in istanti molto vicini tra loro. Il 
secondo è invece quello forse più complesso, e permette di specificare un'animazione descrivendo lo 
stato iniziale di un componente, lo stato finale, la durata e la modalità di passaggio dallo stato iniziale a 
quello finale. Supponiamo di dover animare un' immagine nel suo movimento da un punto A a un punto 
B del display. Se decidiamo di adottare il primo approccio dobbiamo creare una serie di immagini, 
che chiameremo fraine, che rappresentano l'oggetto da animare nelle diverse posizioni dal punto A al 
punto B. Questo tipo di animazioni viene chiamato frame-by-frame e inAndroid vedremo essere 
descritte da una particolare specializzazione della classe Drawable che si chiama AnimationDrawable 
e che è contenuta nello stesso package android. graphics .drawable. Da quanto visto nei capitoli 
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precedenti è infatti abbastanza intuitivo che i diversi frame debbano essere descritti da oggetti 
Drawabie, i quali dovranno poi essere assegnati alla particolare view come si fa normalmente con 
oggetti di questo tipo, ovvero come background. 

Se invece decidiamo di adottare il secondo approccio, ciò che dobbiamo fare sarà descrivere la 
posizione iniziale dell'immagine, la posizione finale, la durata dell'animazione e soprattutto la modalità 
di passaggio dal punto A al punto B, che può variare molto a seconda del tipo di animazione. Si 
potrebbe andare da A a B in modo veloce o lentamente all'inizio per poi accelerare e così via. 
Vedremo come questo concetto venga astratto attraverso la definizione di quello che si chiama 
interpolatore, descritto da particolari specializzazioni dell'interfaccia interpoiator e che assomiglia 
in tutto e per tutto ai Timeinterpoiator del framework di Honeycomb. 

NOTA 

Osservando la documentazione possiamo notare come l'interfaccia Interpolator del precedente 
framework implementi ora l'interfaccia android . animation . Timelnterpolator del nuovo. 

Ciascuna animazione di questo tipo viene poi rappresentata da particolari specializzazioni della 
classe astratta Animation del package android . view . animation che è possibile applicare a una view 
attraverso il seguente metodo: 

public void setAnimation (Animation animation) 

Questa tipologia di animazioni viene chiamata tween, in quanto permette una descrizione di ciò che 
avviene "tra" (betweerì) due punti Nei paragrafi successivi vedremo come, in questa categoria, si 
possa fare una ulteriore classificazione tra animazioni di layout e animazioni di view. Le prime 
permettono di specificare, in modo anche dichiarativo, come un insieme di componenti vengono 
animati all'interno di un proprio container descritto da una particolare ViewGroup. Le seconde sono 
invece quelle più complesse che permettono l'applicazione di trasformazioni matriciali a quella che è la 
matrice dei punti rappresentativa di come una particolare view viene visualizzata nel display. Iniziamo 
quindi lo studio delle animazioni più semplici, ovvero qus^Q frame-by-frame. 

Animazioni frame-by-frame 

Come accennato, questa tipologia di animazioni è quella che prevede la definizione di un insieme di 
frame specificando la modalità con cui questi dovranno essere visualizzati Si tratta di un meccanismo 
simile a quello del vecchio cinema in cui l'animazione era prodotta dalla visualizzazione di sequenze di 
immagini molto vicine tra loro. Come è facile intuire, sono animazioni molto semplici da creare in 
quanto non si dovrà far altro che definire i diversi frame e in qualche modo dichiararli ad Android 
specificando come dovranno essere riprodotti nel tempo. In realtà questo tipo di animazione non 
avviene attraverso la creazione di una specializzazione della classe Animation ma attraverso quella 
che è la classe AnimationDrawable che, come suggerisce il nome, è una particolare specializzazione di 
Drawabie. Se ci pensiamo, un' animazione frame-by-frame può in effètti essere considerata come la 
visualizzazione in sequenza di un insieme di Drawabie. Per questo tipo di animazioni abbiamo creato 
l'esempio all'interno della classe FrameAnimationFragment. Come prima cosa abbiamo definito i 
frame attraverso una serie di immagini relative al movimento di un pallino colorato da sinistra a destra 
che abbiamo inserito all'interno della cartella /res/drawable. Il lettore noterà che sono oggetti 
comunque Drawabie. Il passo successivo consiste nella definizione dell'animazione attraverso un 
documento XML che abbiamo chiamato animation_f rame . xml e che abbiamo inserito nella stessa 
cartella delle immagini Come possiamo vedere nel listato che segue, la definizione dell'animazione è 
avvenuta attraverso l'utilizzo dell'elemento <animation-iist>, all'interno del quale sono stati 
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specificati tanti <item/> quanti sono iframe associando a ciascuno la relativa durata di visualizzazione 

attraverso FattributO android:duration: 
<?xml version="l . 0" encoding="utf-8 " ?> 

<animation-list xmlns : android="http : / /schemas . android . corti/ apk/res/android" 
android : id=" @+id/movingBall " android : oneshot=" f alse"> 
<item android: drawable="@drawable/f rame_l " android : duration="40 " /> 
<item android: drawable=" @drawable/f rame_2 " android : duration="38 " /> 



<item android: drawable=" @drawable/f rame_17 " android: duration="38 " /> 
<item android: drawable=" @drawable/f rame_18 " android: duration=" 4 0 " /> 
</ animation-list> 

Nell'esempio creato abbiamo fatto in modo che F animazione procedesse leggermente più veloce al 
centro e rallentasse ai bordi Una caratteristica di un AnimationDrawabie è quella descritta attraverso 
Fattributo android :oneshot, che indica se l'animazione dovrà essere eseguita una sola volta o essere 
ripetuta. Nel nostro caso abbiamo fatto in modo che la stessa venisse ripetuta più volte. Come detto, 
si tratta di un Drawabie, per cui abbiamo bisogno di una view a cui impostarla come background. Per 
questo motivo abbiamo creato questo semplice layout nel file fragment_frame_animation.xmi: 

<?xml version="l . 0" encoding="utf-8" ?> 

<LinearLayout xmlns : android="http : / / schemas . android . com/apk/ res/android" 
android : orientation="vertical" 
android : layout_width="match__parent " 
android : layout_height="match_parent " 
android : padding= " 1 Odp " > 

<TextView 

android : layout_width="match_parent " 

android: layout_height="wrap_content " 

android: id=" @+id/ animated_textview" 

android : background= " gdrawable/ animat ion_f rame " 

android: text Si ze="38sp" 

android : text=" Sstring/ f rame_animation_label" 
android : gravity= " center " /> 
</LinearLayout> 

Notiamo come si tratti di una Textview, all'interno di un LinearLayout, il cui background è 
appunto la risorsa di tipo AnimationDrawabie definita sopra. Il codice della classe 

FrameAnimationFragment è questo: 

public class FrameAnimationFragment extends Fragment { 
private AnimationDrawable mAnimationDrawable; 
@Override 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, 
Bundle savedlnstanceState) { 
final View view = inflater . inf late (R . layout . f ragment_f rame_animation, 
nuli) ; 

Textview animatedTextView = (Textview) 

view . f indViewByld (R. id . animat ed_text view) ; 
mAnimationDrawable = (AnimationDrawable) 

animatedTextView . getBackground ( ) ; 

return view; 

} 

SOverride 

public void onStartO { 
super . onStart ( ) ; 
mAnimationDrawable . start ( ) ; 

} 

@Override 

public void onStopO { 
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super . onStop ( ) ; 
mAnimationDrawable . stop ( ) ; 



Dopo aver ottenuto il riferimento alla Textview ne abbiamo ottenuto il background, che sappiamo 
essere un'istanza della classe AnimationDrawable perché impostata nel layout. Ci è quindi bastato 
eseguire lo start ( ) e lo stop ( ) in corrispondenza dei metodi di callback onstart ( ) e onstop ( ) , 
rispettivamente. 



AnimationTest 



Frame Animation 



Figura 11.5 Esempio di AnimationDrawable in esecuzione. 

Eseguendo l'applicazione il lettore noterà come il pallino si muova da sinistra verso destra 
riprendendo ogni volta l'animazione da sinistra. Nel caso avessimo voluto fare in modo che il pallino 
oscillasse avremmo dovuto inserire altri frame relativi al moto di ritorno riutilizzando lo stesso insieme 
di Drawable. La classe AnimationDrawable non ci consente infatti, a differenza di quello che accade 
per le specializzazioni di Animation, di decidere la modalità di ripetizione. 



Animazioni dei layout 

Le animazioni frame-by- frame vengono gestite attraverso particolari oggetti Drawable impostabili 
come background di una qualunque view con i risultati visti nel paragrafo precedente. All'inizio 
avevamo però accennato alla presenza del metodo setAnimation ( ) , che permette di associare a una 
view una particolare specializzazione della classe Animation caratteristica di una determinata 
animazione tween. Si tratta di classi che descrivono, tra le altre cose, l'animazione in termini di uno 
stato iniziale, uno stato finale, una durata e un modo per mappare i vari passi dell'animazione nel 
tempo. Nel caso di Un ViewGroup, oltre alla possibilità di utilizzare un' Animation come ereditata dalla 
classe view, si può gestire quella che si chiama layout animation, che viene assegnata attraverso 
l'invocazione del metodo 

public void setLayoutAnimation (LayoutAnimationController controller) 

oppure attraverso l'utilizzo dell'attributo android: layoutAnimation. E un modo per descrivere 
come un'animazione dovrà essere applicata alle view contenute in un viewGroup. Da notare come il 
parametro passato sia un oggetto di tipo LayoutAnimationController, ilcuiruolo è quello di 
Mediator, ovvero di decidere come le eventuali animazioni dovranno essere applicate a ciascuna 
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view contenuta all'interno del ViewGroup. 
NOTA 

Il Mediatore un altro design pattern della GoF di tipo comportamentale che permette di semplificare 
l'interazione tra oggetti diversi nel caso in cui il numero di questi aumenti in modo tale da renderne 
molto difficile la gestione. Nel nostro caso la "mediazione" del LayoutAnimatìonController è quella 

esistente tra l'insieme delle view di un viewGroup e l'animazione da applicare. 

L'implementazione di default di questo componente è quella che consente di avviare l'animazione 
associata a una view di un viewGroup con un ritardo proporzionale all'indice che la prima ha nel 
secondo. Il lettore potrà verificare come sia possibile creare specializzazioni di questa classe 
definendo regole eventualmente diverse nel calcolo del delay. Molto importante è invece la modalità 
con cui si definisce Un LayoutAnimationController ttl modo dichiarativo. Come vedremo nel 
prossimo esempio, si può creare un componente di questo tipo attraverso l'utilizzo di un elemento 

<layoutAnimation/>. 

Le animazioni di tipo tween 

Android mette a disposizione una serie di animazioni che possono essere composte in modi diversi 
e che permettono l'esecuzione di: 

• ridimensionamenti; 

• rotazioni; 

• traslazioni; 

• modifiche della componente alfa. 

Ciascuna di queste animazioni è caratterizzata da una condizione iniziale (f rom), da una condizione 
finale (to), da una durata e da un interpoiator che ha come responsabilità quella di indicare la 
velocità e la modalità per andare da f rom a to nel tempo specificato. Anche in questo caso le 
animazioni vengono descritte in modo dichiarativo attraverso l'utilizzo di opportuni documenti XML 
che ora sono contenuti nella cartella res/anim. Tra gli elementi che è possibile utilizzare all'interno 
dell'XML notiamo: 

• set 

• scale 

• rotate 

• translate 

• alpha 

dove, insieme a quelli corrispondenti alle operazioni descritte in precedenza, notiamo l'elemento 
<set /> che ci permetterà di comporre più tipi di animazioni in ima unica applicando, ancora ima volta, 
il pattern Composite. 

A ciascuna animazione viene associata una durata attraverso l'attributo android: duration 0 
l'invocazione del metodo 

public void setDuration ( long durationMillis ) 

Il valore viene espresso in millisecondi, non può essere negativo e ha 0 come defàult. Questo 
significa che se non viene specificato, l'animazione non ha effètto. Come le altre grandezze che 
andiamo a scrivere si tratta di un valore che possiamo esprimere direttamente o attraverso il 
riferimento a ima risorsa o proprietà di un particolare tema. Specialmente nel caso in cui si 
compongano diverse tipologie di animazione attraverso l'elemento <set/>, si può ritardare l'inizio di 
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una particolare animazione rispetto al tempo di start stabilito. Per farlo è possibile utilizzare l'attributo 
android:startoffset oppure invocare il seguente metodo dove il parametro rappresenta dei 
millisecondi: 

public void setStartOff set (long startOffset) 

Come vedremo successivamente, a ciascuna view si possono applicare delle trasformazioni 
attraverso la definizione di opportune matrici descritte da istanze della classe Matrix. Il riferimento a 
tali matrici ci verrà fornito da un oggetto di tipo Transf ormatìon passato come parametro del metodo 

protected void applyTransf ormatìon ( f loat interpolatedTime, Transf ormation t) 

che ogni Anìmation implementa. Quando un'animazione viene applicata a una view possiamo 
scegliere se renderla o meno persistente. Nel caso si intendesse mantenere come stato della view 
quello finale dell'animazione è possibile utilizzare il metodo 

public void setFillAfter (boolean f illAfter) 

passando true come valore del parametro. Lo stesso risultato si potrà ottenere attraverso 
l'attributo android : f iiiAfter. Nel caso in cui si gestissero più animazioni attraverso un elemento 
<set/> o la creazione di un AnìmationSet, si potrebbe avere la necessità di applicare una particolare 
trasformazione prima dell'istante effettivo di start. In questo caso il metodo a cui passare un valore 
true del parametro è il seguente: 

public void setFillBef ore (boolean fillBefore) 

mentre il corrispondente attributo sarà android: fiiiBef ore. L'utilizzo di questi metodi o attributi è 
poi abilitato o meno attraverso il metodo 

public void setFillEnabled (boolean fillEnabled) 

o con il corrispondente attributo android: fiiiEnabied, che di default è a false. 
Una volta creata un'animazione si può stabilire il numero di volte che la stessa dovrà essere ripetuta 
attraverso l'attributo android :repeatcount oppure il metodo 

public void setRepeatCount (ìnt repeatCount) 

Il valore del parametro pari ad Anìmation. infinite (che corrisponde a -1) indica che 
l'animazione viene ripetuta continuamente. In caso contrario verrà ripetuta il numero di volte 
specificato. È bene fare attenzione che il valore 0 indica nessuna ripetizione. Oltre a questo, si può 
anche impostare la modalità di ripetizione attraverso l'attributo android: repeatMode o il metodo 

public void setRepeatMode (int repeatMode) 

dove il parametro può assumere uno dei valori descritti dalle costanti Animatìon. restart o 
Animation. reverse. Nelprimo caso l'animazione viene ripetuta dall'inizio, mentre nel secondo viene 
ripetuta in ordine inverso per ritornare dalla condizione finale a quella iniziale. 

Infine, attraverso l'attributo android : zAdjustment SipuÓ indicare il dove il risultato dell'animazione 
verrà visualizzato rispetto al resto del contenuto della view alla quale l'animazione è stata applicata. 
Lo stesso è possibile attraverso il metodo 

public void setZAd justment (ìnt zAdjustment) 

dove i valori sono quelli descritti dalle costanti Anìmation . zorder_normal, Animation . zorder_top 
e Anìmation. zorder_bottom. Ilprimo valore indica che ranimazione viene visualizzata secondo quello 
che è il suo implicito valore di z, mentre gli altri permettono rispettivamente di visualizzare 
l'animazione al di sopra o al di sotto di quanto relativo alla view. È importante specificare che questo 
attributo non permette una gestione dinamica dell'animazione lungo l'asse Z, cosa che sarà possibile 
successivamente attraverso la realizzazione di particolari trasformazioni personalizzate. 
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Interpolator 



Si tratta di quegli oggetti che abbiamo visto nelle animazioni in Honeycomb. Android otfre diversi 
tipi di interpoiator, che abbiamo elencato nella Tabella 11.1. 

Tabella 11.1 







AccelerateDeceleratelnterpolator 


L'animazione accelera all'inizio e alla fine rallentando nel mezzo. 


Acceleratelnterpolator 


L'animazione parte piano e poi accelera. 


Anticipatelnterpolator 


L'animazione inizia all'indietro per un tempo dipendente dal valore di 

tension per pOÌ prOSegijire COme fOSSe Un Acceleratelnterpoator. 


AnticipateOvershootlnterpolator 


L'animazione inizia all'indietro come per l'Anticipatemterpoiator e poi 
prosegue oltre la posizione finale di un'entità legata al valore 
dell'attributo extraTension per poi raggiungere la posizione finale. 


Bouncelnterpolator 


L'animazione raggiunge lo stato finale da quello iniziale con un 
movimento oscillatorio. 


Cyclelnterpolator 


Permette di eseguire l'animazione un numero di volte specificato dal 
valore dell'attributo c Y cie S con un andamento oscillatorio. 


Deceleratelnterpolator 


L'animazione parte forte per poi decelerare secondo un fattore 
specificato dall'attributo factor. 




L'animazione rimane costante dall'inizio alla fine. 


Overshootlnterpolator 


L'animazione parte come fosse quella di un Acceieratemterpoiator per 
poi proseguire oltre la posizione finale di una quantità legata 
all'attributo tension e poi ritornare su questa successivamente. 



La definizione del particolare interpoiator può avvenire in modo dichiarativo attraverso l'utilizzo 
di elementi che riprendono il nome delle classi nella tabella. Questo significa che, per esempio, la 
definizione di un Anticipatelnterpolator che utilizza un valore di tension paria 0.5 può essere 
dichiarato in un documento XMLo all'interno di un elemento <set/> nelseguente modo: 



<?xml version="l . 0" encoding="ut f-8 " ?> 

Onticipatelnterpolator xmlns : android="http : / /schemas . android . corti/ apk/ re s /android" 
android : tension=" 0 . 5 " /> 

Sarà poi possibile usare l'attributo android: interpolator della particolare animazione oppure uno 
di questi due metodi: 

public voi setlnterpolator (Interpolator ì) 

public void setlnterpolator (Context context, int resID) 

dove il primo necessita di un riferimento all' interpolator, mentre il secondo usa solo il riferimento 
alla risorsa definita in precedenza. 

Alcuni esempi 

Non ci resta che vedere degli esempi di questi strumenti per animare un layout; nel nostro caso 
sarà una Gridview; ma che potrà essere una qualunque altra specializzazione di vìewGroup. Come 
primo tipo di animazione utilizziamo quella associata all'elemento <scaie/>, che consente di 
ridimensionare una view da una dimensione iniziale a una finale. Consideriamo il file 
scaie_animation.xmi che abbiamo inserito nella cartella res/anim: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

< scale xmlns : android="http : / /schemas . android. com/ apk/ res/ android" 
android: f romXScale=" 0 . 5 " android : toXScale=" 1 . 0 " 
android: f romYScale=" 0 . 5" android : toYScale=" 1 .0" 
android :pivotx="50%p" android :pìvotY=" 5 0%p" 
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android: duration=" 1000 " android: startOf f set="50" 
android: interpolator=" @anim/bounce_interpolator " 

/> 

Notiamo innanzitutto come lo stato iniziale venga rappresentato dall'insieme degli attributi 

android: f romXScale 
android: toXScale 
android: f romYScale 
android: toYScale 

i quali permettono di specificare quella che è la percentuale di ridimensionamento iniziale e finale 
della view rispetto a quelle che sono le dimensioni totali Un valore pari a 1 .0 ha come significato 
quello di lasciare inalterata la view. Nell'esempio i valori indicati consentono di indicare come 
dimensione dipartenza quella che prevede un resize del 50% e come dimensione finale quella 
disponibile nel display. Molto importanti sono anche gli attributi 

android :pivotX 
android : pivotY 

che permettono di specificare le coordinate del punto da considerare come centro per il 
ridimensionamento. Se non specificate, come punto di riferimento verrà preso l'origine degli assi, che 
nel display è quello in alto a sinistra. In quel caso vedremmo la view ridimensionarsi mantenendo 
inalterato il punto in alto a sinistra. Nel nostro esempio abbiamo utilizzato un valore di 50% per 
entrambe le coordinate. Questo ha come significato quello di considerare come punto di riferimento 
quello centrale. In questo caso è comunque bene fare attenzione ai valori impostati in quanto, mentre 
un valore di 50% indica la metà della view stessa, un valore 50%p (con la p dopo %) indica il 50% 
rispetto al contenitore. Un valore senza il segno % indica invece una quantità assoluta, Se si devono 
impostare in modo programmatico queste informazioni la classe scaieAnimation introduce il 
concetto dipivotType, ovvero di un modo per esprimere il significato del valore impostato a ciascuna 
dimensione di pivot. Un tipo associato alla costante Inimation.ABSOLUTE permette di specificare un 
valore assoluto; attraverso le costanti Animation . relative_to_self e 

Animation . relative_to_parent sipuò invece indicare che le dimensioni specificate sono relative 
all'elemento stesso o alparent, rispettivamente. 

Gli altri attributi del nostro esempio sono quelli generici di ciascuna Animation e ci permettono, 
nello specifico, di descrivere un'animazione della durata di 1 secondo, che viene avviata dopo 50 
millisecondi dal tempo di start e che utilizza come interpoiator quello descritto all'interno del file 

bounce_interpolator . xml in res/aflim. 
<?xml version=" 1 . 0 " encoding="utf-8" ?> 

<bounceInterpolator xmlns : android="http : / / schema s . android. com/ apk/ res/ android" / > 

Dopo la definizione del documento XML che descrive l'animazione dobbiamo definire il particolare 
layout animation attraverso il documento che abbiamo inserito nel file scaie_controiier .xml sempre 
in res/anim 

<?xml version="l . 0" encoding="utf-8" ?> 

<layoutAnimation xmlns : android="http : / / schemas . android . oom/apk/res/ android" 
android: anìmation=" @anim/scale_animation" 
android: animationOrder="normal" 
android: delay="30%" android : startOf f set=" 50 " 

/> 

Notiamo come venga definito attraverso un elemento <iayoutAnimation/> con una serie di attributi 
tra cui android : animation per il riferimento alla particolare animazione da utilizzare. Attraverso 
l'attributo android : animationOrder è infatti possibile indicare se le animazioni, eventualmente 
contenute nell'elemento <set/> a cui si è accennato in precedenza, debbano essere eseguite 
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nell'ordine indicato, in ordine inverso o in modo casuale. Se impostato programmaticamente 
attraverso il metodo 

public void setOrder(int order) 

i possibili valori sono rispettivamente quelli definiti dalle costanti order_normal, order_reverse e 
order_random della classe LayoutAnimationControiier. Oltre a queste informazioni si può poi 
specificare il ritardo con cui ciascuna animazione verrà applicata alle diverse view del viewGroup. Nel 
nostro esempio un valore del 30% indica che a ciascuna view verrà applicata l'animazione con un 
ritardo del 30% rispetto alla durata complessiva della stessa. L'attributo relativo all'oflset ha lo stesso 
significato di quello visto per l'anirnazione. Un aspetto interessante riguarda invece la possibilità di 
specificare anche per il layout|\nimatìonControiier un particolare interpolate^ attraverso 
l'attributo android:interpoiator. In questo caso il significato è quello di interpolate^ per la 
definizione dei ritardi delle diverse view in modo, per esempio, da tàr partire le animazioni molto 
vicine tra loro per le prime view rallentando successivamente nel caso di un 

Deceleratelnterpolator. 

Una volta definito il LayoutAnimationControiier che fa riferimento alla particolare animazione, 
non ci resta che applicarlo al nostro viewGroup, ovvero a una Gridview come descritto nel seguente 

documento di layout nel file fragment_scale_layout_animation.xmi: 
<?xml version="l . 0" encoding="utf-8" ?> 

<LinearLayout xmlns : android="http : / /schemas . android . corti/ apk/res/ android" 
android : orientatìon="vertical" 
android : layout_width=" f ill_parent " 
android : layout_height=" f ill_parent "> 

<GridView 

android: id=" @+id/animatedView" 

android : layout_height=" f ill_parent " 

android: layout_width=" f ìll_parent " 

android: layout Animation="@anim/ scale_controller" 

android:persistentDrawingCache="animation | scrolling" 

android : numColumns=" @integer/grid_column_number " > 
</GridView> 
</LinearLayout> 

IlLayoutAnìmationControiier è stato assegnato alla Gridview attraverso l'attributo 
android : layoutAnimation corrispondente al metodo setLayoutAnimation ( ) della classe ViewGroup 
già descritta. Un'ultima considerazione prima di testare l'esecuzione dell'applicazione riguarda 
l'utilizzo dell'attributo android:persistentDrawingCache, il quale permette l'impostazione di una 
cache del risultato di un'animazione o di uno scorrimento per l' ottimizzazione delle prestazioni Nulla è 
gratis, per cui l'utilizzo di una cache presuppone il ricorso a una quantità di memoria superiore, che 
però porta il vantaggio di non dover subire eventi di garbage collection troppo frequenti 
Nell'esempio abbiamo impostato come cache quella relativa allo scorrimento (il default) e alla 
gestione delle animazioni 

Per le successive tipologie di animazioni descriveremo solamente i corrispondenti documenti XML 
senza ripetere i dettagli delle impostazioni descritte finora. Prima di farlo diamo comunque un'occhiata 
al codice Java relativo al fragment di test che, per come sono organizzate le risorse relative alle 
animazioni, si differenzierà solamente per il layout da visualizzare. A tale scopo abbiamo creato la 
classe astratta |^ bstractLayoutAnimationFragment, che definisce tutto ciò che riguarda la gestione 
dell' adap ter della Gridview lasciando indefinito proprio l'identificatore del layout: 

public abstract class AbstractLayoutAnimationFragment extends Fragment { 
private static final int ELEMENT_DIM = 100; 

481 



@Override 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, 
Bundle savedlnstanceState) { 
final View view = inflater . inf late (get Layout Id () , nuli); 

Stringi] data = new String [ELEMENT_DIM] ; 
for (int i = 0; i < data . length; i++) { 
datali] = "LABEL #"+i; 

} 

ArrayAdapter<String> adapter = new ArrayAdapter<String> (getActivity () , 

android . R . layout . simple_list_item_l , data) ; 
GridView gridView = (GridView) view. f indViewByld (R. id. animatedView) ; 
gridView. setAdapter (adapter) ; 

return view; 

} 

public abstract int getLayoutId() ; 

} 

Per testare una particolare animazione basterà quindi creare una specializzazione di 
AbstractLayoutAnimationFragment definendo come valore di ritorno del metodo getLayoutid o 
l'identificatore del corrispondente documento XML di layout. Da quanto descritto in precedenza il 
fragment relativo alla dimostrazione di una ScaleAnimation è banale: 

public class ScaleLayoutAnimationFragment extends AbstractLayoutAnimationFragment { 
gOverride 

public int getLayoutId() { 

return R. layout . f ragment_scale_layout_animation; 

} 

} 

Non ci resta che verificare il risultato della animazione di tipo scaie appena definita ottenendo un 
qualcosa che possiamo solo dedurre dall' immagine nella Figura 11.6. 
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Figura 11.6 Screenshot relativo all'animazione di tipo scale. 



RotateAnimation 

Un'animazione di questo tipo consente di eseguire delle rotazioni da una posizione iniziale a una 
posizione finale attraverso la definizione di un documento XML all'interno del quale viene usato 
l'elemento <rotate/>. Oltre agli attributi comuni a tutte le Animation, una RotateAnimation può 
essere così specificata: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

< rotate xmlns : android="http : / /schemas . android . com/apk/ res/android" 

android: f romDegrees=" 0 " android:toDegrees="360" android:pivotx="30%" 
android: duration=" 1000 " 
android :pivotY=" 30%" 

android: interpolator=" @anim/ anticipate_interpolator " /> 

Questa volta l'animazione corrisponde a una rotazione da un angolo dipartenza a un angolo di 
arrivo espressi attraverso gli attributi android: fromDegrees e android :toDegrees E importante 
ricordare che si tratta di angoli espressi in gradi. Il significato degli altri attributi è lo stesso del caso 
precedente. Per variare abbiamo solamente modificato il punto di riferimento dell'animazione e 

483 



l'interpolatore utilizzato. Anche in questo caso serve un LayoutAnimationCont roller che abbiamo 
descritto nel file rotate_controller . xml, analogo nella forma a quello del caso precedente: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<layoutAnimation xmlns : android="http : / / schemas . android . com/apk/res/android" 
android : animation= " @anim/ rotate_animation " 
android : animat ionOrder= " random" 

android: delay="20%" 
android: startOf f set="50" /> 

Il riferimento all'animazione sarà relativo alla rotazione. Il layout è ora contenuto nel file 
fragment_rotate_iayout_animation.xmi in resAayout e sarà analogo a quello già visto in cui 
abbiamo modificato il riferimento al LayoutAnimationCont roller. Il risultato è mostrato nella Figura 
11.7; il lettore potrà testarlo avviando l'applicazione. 
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Figura 11.7 Screenshot relativo all'animazione di tipo rotate. 

Dai diversi file di configurazione che abbiamo creato possiamo notare come siano stati creati tipi di 
interpolatori diversi al fine di testare il più possibile. 
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TranslateAnimation 



Attraverso Una TranslateAnimation è possibile eseguire animazioni che consistono nel traslare una 
particolare view da una posizione iniziale a una posizione finale. Anche in questo caso abbiamo 
realizzato il seguente documento XML all'interno del file l ranslate_animation . xml ttl res/anim: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<translate xmlns : android="http : //scheraas . android . com/ apk/res/ andrò id" 
android: fromXDelta="100%" android : toXDelta=" 100%" 
android: f romYDelta=" 0 . 0 " android : toYDelta=" 0 .0" 
android :pivotX=" 50%" android :pivotY=" 50%" 
android : duration=" 1000 " android: startOf f set="50 " 

android : interpolator=" @anim/ accelerate_decelerate_interpolator " /> 

Vediamo come gli attributi che caratterizzano questo tipo di animazione siano quelli relativi alla 
posizione iniziale e finale degli elementi Un'importante considerazione riguarda la modalità di 
rappresentazione dei valori. Nel caso in cui si utilizzasse una notazione con la percentuale, come nel 
caso della coordinata X dell'esempio, il significato è quello di grandezza relativa al componente 
stesso. Un valore del tipo %p indica invece una percentuale relativa al componente padre. Infine, con 
un valore senza %, come nel nostro esempio per le Y, il significato è quello di valore assoluto. Il layout 
ora è contenuto nel file f ragment_translate_layout_animation . xml m resAayout e il risultato si può 
intuire dalla Figura 11.8. 
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Figura 11.8 Screenshot relativo a un'animazione di tipo translate. 



AlphaAnimation 

Un ultimo tipo di animazione tween che intendiamo gestire è F AlphaAnimation, che permette di 
modificare il valore della componente alpha di uno o più componenti Nel nostro caso abbiamo 
creato il seguente documento alpha_animation . xml nella cartella res/anim: 

<?xml version="l . 0" encoding="ut f-8 " ?> 

<alpha xmlns : androìd="http : / / schema s . android. com/ apk/res/android" 
android: f romAlpha="0 .0" 
android :toAlpha="l .0" 
android: duration=" 800 " 
android: startOf f set="50" 

android : interpolai; or="@anim/bounce_interpolator " 

/> 

In questo caso vengono utilizzati gli attributi android: startAipha e android :toAipha per 
specificare il valore iniziale e finale della componente alpha della view da animare. Un valore pari a 
0.0 indica la completa trasparenza, a differenza di un valore paria 1.0 che indica invece la completa 

Opacità. Questa volta illayOUtè Contenuto in un file di nome fragment_alpha_layout_animation.xml. 

Non si tratta di una vera e propria animazione, in quanto non c'è alcun movimento di componenti. Si 
è comunque pensato di inserire questo tipo di trasformazione in questo package come particolare 
implementazione diAnìmation. È un' animazione abbastanza difficile da rappresentare con una sola 
immagine, per cui ne lasciamo la verifica al lettore, il quale dovrà semplicemente eseguire 
l'applicazione AnìmationTest e selezionare l'opzione corrispondente. 

AnimationSet 

Abbiamo visto che un'animazione descrive una tecnica per applicare in modo progressivo nel 
tempo, una serie di trasformazioni che possono consistere nella traslazione, rotazione e resize di un 
componente oltre che nella variazione della componente alpha, ovvero della trasparenza. Attraverso 
un oggetto di tipo AnimationSet è possibile comporre una o più animazioni in un elemento trattandolo 
come se fosse una singola animazione. Per farlo è sufficiente utilizzare l'elemento <set/> inserendo al 
suo intemo l'insieme di definizioni di animazioni come già visto. Un aspetto molto importante in questi 
casi è l'ordine di esecuzione delle animazioni definite in un elemento <set/>. Se non specificato 
attraverso l'attributo di offset, tutte le animazioni di una setAnimation partono contemporaneamente 
per cui, nel caso non fosse il risultato desiderato, bisognerà fare in modo che un'animazione parta 
dopo che un'altra ha concluso la propria esecuzione. Per farlo si devono utilizzare gli strumenti visti 
relativamente al ritardo nella partenza e alla durata di ciascuna animazione. Nel nostro esempio non 
abbiamo fatto altro che inserire tutte le definizioni precedenti all'interno di un unico elemento <set/> 
nel file set_anìmation.xmi in res/anim: 

<?xml version="l . 0" encoding="utf-8 " ?> 

<set xmlns : android="http : / /schemas . android . com/ apk/ res/ android" 
android: interpolator=" @anim/bounce_interpolator " 
android : shareInterpolator="true"> 
<translate 

android: f romXDelta=" 100% " 

android :toXDelta=" 100%" 

android: f romYDelta=" 0 . 0" 

android:toYDelta="0 . 0" 

android :pivotX=" 50%" 

android :pivotY=" 50%" 
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android:duration="1000" 
android: startOf f set="50"/> 
<scale 

android: f romXScale=" 0 . 5" 

android:toXScale="l . 0" 

android: f romYScale=" 0 . 5" 

android:toYScale="l . 0" 

android : pivotX=" 50%p" 

android : pivotY=" 50%p" 

android :duration=" 10 00" 

android: startOf fset="50"/> 
<rotate 

android: f romDegrees="0" 

android : toDegrees="3 60 " 

android :pivotX=" 30%" 

android :duration=" 10 00" 

android :pivotY=" 30% "/> 
<alpha 

android: fromAlpha="0 . 0" 

android: toAlpha="l . 0" 

android :duration=" 800" 

android: startOf fset="50"/> 

</set> 

Notiamo come sia possibile specificare Ufi Interpolator anche per una setAnimation in quanto 
specializzazione di Animation. Questo grazie l'attributo android: interpolator, presente inquanto si 
tratta comunque di una specializzazione di Animation. Molto interessante è poi l'opportunità di 
utilizzare l'attributo android: shareinterpoiator, attraverso il quale si può lare in modo che tutte le 
animazioni nel <set/> condividano con esso lo stesso interpolatore. Nel caso in cui ciascuna 
animazione specificasse il proprio interpolator, il valore ditale attributo sarà false. Ora il nome del 
file contenente il layout è fragment_set_iayout_anìmation.xmi e, come prima, lasciamo a lettore il 
test dell'animazione, che sarà questa volta abbastanza "animata". 

Animazioni delle view 

Nel paragrafo precedente abbiamo utilizzato una serie di specializzazioni della classe Animation 
per la realizzazione di animazioni che abbiamo definito di layout. Si è trattato di componenti in grado 
di applicare delle trasformazioni a quella che è la matrice di visualizzazione di una view data 
dall'insieme delle informazioni di colore (ARGB) e di posizione di ciascun pixel. Attraverso 
l'applicazione di opportune trasformazioni matriciali si può eseguire ciascuna delle animazioni già viste. 
Il punto di estensione che Android fornisce per la realizzazione di animazioni personalizzate è 
contenuto all'interno della classe Animation e si esprime attraverso l'implementazione della seguente 
operazione: 

protected void applyTransf ormatìon (f loat interpolatedTime, Transf ormatìon t) 

Ogni particolare Animation implementerà l'operazione applyTransf ormation o per applicare delle 
trasformazioni matriciali all'insieme dei punti della view animata. Il parametro interpolatedTime è un 
valore di tipo float che vale 0.0 all'inizio dell'animazione e 1.0 alla fine. L'insieme dei valori possibili 
dipende da particolare interpolator utilizzato. Ai fini della trasformazione che 1' Animation vuole 
creare, è di fondamentale importanza il secondo parametro di tipo Transf ormation, che incapsula le 
informazioni di una trasformazione mantenendo un riferimento a un oggetto di tipo Matrix. Per 
realizzare delle animazioni personalizzate dovremo semplicemente creare delle specializzazioni della 
classe Animation implementando la logica di trasformazione all'interno del metodo 
applyTrasf ormation () . Senza entrare nel dettaglio di trasformazioni complesse, vediamo un semplice 
esempio di creazione di un' animazione personalizzata che utilizza l'oggetto Matrix per applicare delle 

487 



semplici trasformazioni. Quello che vogliamo fare è applicare un' animazione di questo tipo alla nostra 
Gridview in modo da ruotarla di 180 gradi. La nostra implementazione personalizzata diAnimation, è 
descritta nella classe invertAnimation di cui riportiamo le istruzioni di interesse: 

public class InvertAnimation extends Animation { 

private final static float DEFAULT_ROTATION_RATE = 1. Co- 
private float rate = DEFAULT_ROTATION_RATE ; 
private float pivotX; 
private float pivotY; 
@Override 

public void initialize (int width, int height, int parentwidth, 
int parentHeight ) { 
super . initialize (width, height, parentwidth, parentHeight); 
pivotX = width / 2; 
pivotY = height / 2; 
setDuration (1000L) ; 
setFillAfter (true) ; 

} 

public float getRateO { 
return rate; 

} 

public void setRate (float rate) { 
this.rate = rate; 

} 

SOverride 

protected void applyTransf ormation ( float interpolatedTime, 

Transf ormation t) { 

Matrix matrix = t . getMatrix () ; 

float rotateValue = interpolatedTime * 180f * rate; 
rotateValue = (rotateValue < 180f) ? rotateValue : 180f; 
matrix . setRotate (rotateValue, pivotX, pivotY); 

} 

} 

Quando un'animazione viene assegnata a una particolare view, ne viene invocato il metodo 
initialize ( ) per la comunicazione di quelle che sono le dimensioni della view stessa e del relativo 
container. E un metodo che possiamo facilmente utilizzare come callback di inizializzazione delle 
caratteristiche dell'animazione. Nel nostro caso si tratta di specificare il punto rispetto al quale 
eseguire una rotazione, la durata ed eventualmente (lo lasciamo al lettore), un particolare 
interpoiator. Molto interessante è l'utilizzo del metodo setFillAfter o che ci consentirà di 
mantenere attivo lo stato finale della view al termine dell'animazione. Il lettore potrà verificare come 
nel caso di un valore true lo stato finale dell'animazione è quello di visualizzare la Gridview ruotata di 
1 80 gradi (a differenza di quanto accadrebbe nel caso in cui il valore passato fosse false). 

Il secondo passo nella definizione della nostra animazione è Voverride del metodo che ne 
implementa la logica, ovvero: 

@Override 

protected void applyTransf ormation ( float interpolatedTime, Transf ormation t) { 
Matrix matrix = t . getMatrix () ; 

float rotateValue = interpolatedTime * 180f * rate; 
rotateValue = (rotateValue < 180f) ? rotateValue : 180f; 
matrix . setRotate (rotateValue, pivotX, pivotY); 

} 

Qui è stato possibile ottenere il riferimento alla matrice attraverso il riferimento t ransf ormation 
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passato come parametro. La matrice ottenuta inizialmente è quella particolare matrice detta unità, 
ovvero che non produce alcuna modifica. Senza necessariamente modificare ogni elemento della 
matrice, la classe Matrix ci mette a disposizione i seguenti metodi set per l'esecuzione di operazioni 
ormai classiche: 

• rotate (rotazione); 

• scaie (scala); 

• translate (traslazione). 

A queste vengono aggiunte quelle di 

• reset (reimpostazione); 

• skew (inclinazione). 

Attraverso l'operazione di reset si può riportare la matrice nello stato iniziale di matrice d'identità. 
Il metodo skew consente invece di applicare una trasformazione che inclina ciò che è visualizzato. 
Nell'esempio che abbiamo creato abbiamo utilizzato una semplice operazione di rotazione di una 
quantità dipendente dall'istante dell'animazione ottenuto come primo parametro. 

Per quello che riguarda il nostro fragment non abbiamo fatto altro che creare un'istanza della classe 
InvertAnimation impostandola poi come animazione della GridView. Da notare come sia stato 
utilizzato l'attributo android: onClick per l'esecuzione del metodo Itartknimationo nel fragment. 
Il risultato è quello nella Figura 11.9. Lasciamo al lettore la verifica di cosa succede nel caso in cui il 
metodo setFiiiAfter o non venga invocato con un valore true del parametro. 

Da quanto realizzato ci accorgiamo che le animazioni utilizzate nel caso dei layout non siano altre 
che specializzazioni di Animation create nel modo descritto conia sola differenza di permetterne la 
definizione attraverso opportuni documenti XML. 

Un'importante osservazione in relazione all'uso della classe Matrix riguarda la presenza di diversi 
metodi del tipo pre e post. Supponiamo di avere due matrici che chiamiamo mi ed m2 relative a 
particolari trasformazionL Se indichiamo con * l'operazione di moltiplicazione righe/colonne possiamo 
affermare che in generale 
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Figura 11.9 Screenshot relativo alla rotazione di 180 gradi della GridView. 

mi * m2 ^ m2 * mi 

ovvero che non vale la proprietà commutativa. La classe Matrix ci permette di eseguire le precedenti 
operazioni nel seguente modo: 

mi * m2 = mi . preConcat (m2 ) = m2 .postConcat (mi) 
m2 * mi = mi . postConcat (m2 ) = m2 . preConcat (mi ) 

Lo stesso vale nel caso delle altre tipologie di animazioni. Attraverso le seguenti righe di codice 

matrix = tranf ormation . getMatrix ( ) ; // matrix è l'identity mi 

matrix . setRotate ( 0 . 5 ) ; // matrix = m2 dove m2 è la rotazione 

matrix . preTranslate ( 10, 20 ) ; // matrix = m3 *matrix dove m3 è il translate 

matrix . postScale (2 , 2 ) ; // matrix = matrix * m4 dove m4 è lo scale 

otteniamo inizialmente il riferimento alla matrice unità attraverso l'oggetto Trans f ormation passato 
come parametro dal metodo applyTransf ormation () . Poi applichiamo la matrice m2, che permette di 
eseguire una rotazione. Avendo utilizzato il prefisso set ora la matrice referenziata è quella di 
rotazione. Il passo successivo è quello di applicare una traslazione attraverso un metodo con prefisso 
pre. Questo significa che se m3 è la matrice che contiene i dati della traslazione, la moltip Reazione con 
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quella corrente avviene mettendo m3 come primo operando. Infine viene applicata una scaie con il 
prefisso post per cui, se m4 è la matrice della traslazione, essa viene usata come secondo operando. 
In sintesi la matrice applicata sarà questa: 

matrix = (m3 *m2)*m4 

Utilizzo della classe Camera 

Una classe del package android. graphics che può essere utilizzata nell'implementazione delle 
animazioni viste finora è sicuramente camera, la quale non deve essere confusa con lo strumento che i 
dispositivi Android solitamente hanno per l'acquisizione di immagini. Si tratta di una classe, poco 
documentata, che permette di applicare alle view delle trasformazioni simili a quelle che si 
otterrebbero guardando la view attraverso una telecamera che si può muovere nello spazio. La 
possibilità di poter gestire anche la dimensione Z è forse la sua caratteristica principale. Anche in 
questo caso abbiamo realizzato un esempio attraverso il documento di layout 

fragment_camera_animation.xml e la classe lameraAnimationFragment. L' animazione è invece 

implementata all'interno della classe cameraAnimation: 

public class CameraAnimation extends Animation { 

private final static float DEFAULT_ROTATION_RATE = 1. Co- 
private float rate = DEFAULT_ROTATION_RATE ; 
private float pivotX; 
private float pivotY; 
SOverride 

public void initialize (int width, int height, int parentwidth, 
int parentHeight ) { 
super . initialize (width, height, parentwidth, parentHeight); 
pivotX = width / 2 ; 
pivotY = height / 2; 
setDuration (1000L) ; 
setFillAfter (true) ; 

} 

public float getRateO { 
return rate; 

} 

public void setRate ( float rate) { 
this.rate = rate; 

} 

@Override 

protected void applyTransf ormation ( float interpolatedTime, 
Transf ormation t) { 
Matrix matrix = t . getMatrix () ; 
Camera camera = new Camera (); 
camera . save ( ) ; 

camera . rotateX (interpolatedTime * 60); 
camera . getMatrix (matrix) ; 
matrix . preTranslate (-pivotX, -pivotY) ; 
matrix . postTranslate (pivotX, pivotY) ; 
camera . restore ( ) ; 

} 

} 

Notiamo innanzitutto la presenza della variabile d'istanza camera acuiè stato assegnato il 
riferimento a un oggetto camera che andremo a riutilizzare nelle diverse invocazioni del metodo di 
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trasformazione. Dopo aver ottenuto il riferimento alla matrice corrente abbiamo invocato il metodo 
save o sull'oggetto camera. Questo consente di catturare lo stato corrente della view come se fosse 
una foto. A questo punto ci si può muovere come se si avesse in mano una telecamera. Nel nostro 
caso abbiamo semplicemente eseguito una rotazione che al termine della animazione raggiunge i 60 
gradi rispetto all'asse delle ascisse. Al termine della rotazione chiediamo alla camera qual è la matrice 
che dovremo applicare alla view per ottenere quello che la stessa vedrebbe in quel momento. Per 
farlo utilizziamo il metodo getMatrix ( ) . Al termine dell'elaborazione non ci resta che richiamare il 
metodo restore o per portare la camera nello stato iniziale. Un'ultima considerazione riguarda 
l'utilizzo di due metodi di traslazione in pre e post rispetto a quello di applicazione della 
trasformazione della camera. Infatti, se non specificato diversamente, il punto di riferimento è l'origine 
degli assi in alto a sinistra; nel nostro caso vogliamo invece utilizzare come punto di riferimento quello 
centrale dello schermo. Anche in questo caso lasciamo il test al lettore, che dovrebbe osservare una 
rotazione della Gridview sull'asse Y. 

Animator 

Concludiamo l'argomento animazioni descrivendo brevemente alcuni componenti che avevamo 
tralasciato nel capitolo relativo ai layout e in particolare in relazione al frameLayout. Come 
ricordiamo, si tratta di un particolare ViewGroup che permette di visualizzare o nascondere alcune 
delle view invocando su di esse il metodo setvisibiiity o . La classe viewAnimator consente di 
aggiungere al FrameLayout anche la possibilità di applicare delle animazioni sia durante il passaggio di 
una view dallo stato visibile a quello non visibile (gone) sia viceversa. Per farlo è sufficiente utilizzare i 
metodi 

public void setlnAnimation (Animation inAnimation) 

public void setlnAnimation (Context context, int resourcelD) 

public void setOutAnimation (Animation outAnimation) 

public void setOutAnimation (Context context, int resourcelD) 

per applicare una particolare animazione al processo di visualizzazione (in) o di non visualizzazione 
(out) di una data view. Ne esistono due diversi a seconda della modalità con cui Fanimazione viene 
referenziata. 

Si tratta di specializzazioni della classe viewAnimator, che è un'estensione del FrameLayout, a cui 
aggiunge le animazioni da applicare al passaggio tra le diverse view in esso contenute. Abbiamo infatti 
visto che un FrameLayout permette di visualizzare o nascondere le view che racchiude agendo 
semplicemente sulla proprietà di visibilità. La classe ViewAnimator consente quindi di specificare 
un'eventuale animazione da applicare nel caso di ingresso o di uscita da una particolare view. Della 
classe esistono poi due specializzazioni che si chiamano viewFiìpper e viewswitcher. La prima 
permette di visualizzare una delle view che contiene e poi passare alla visualizzazione delle seguenti in 
modo automatico, a intervalli regolari specificati dal valore della sua proprietà fiìpintervai, che si 
può assegnare sia attraverso F omonimo attributo sia con il relativo metodo set, come è possibile 
vedere nelle corrispondenti API. È quindi un componente che permette di implementare una sorta di 
gallery automatica. 

Attraverso uno viewswitcher si può invece gestire solamente una coppia di view di cui è possibile 
ottenere un riferimento sia passandole attraverso il metodo addview ( ) sia fornendo l'implementazione 
dell'interfaccia viewswitcher .viewFactory. Se poi le view da gestire attraverso lo switcher sono 
delle immagini o del testo sarà sufficiente utilizzare le ulteriori specializzazioni descritte dalle classi 



492 



imageswitcher e Textswitcher. Data la semplicità dei componenti si lascia al lettore la creazione di 
un esempio. 

Animare il passaggio tra activity diverse 

Come esempio di utilizzo delle animazioni nella nostra applicazione abbiamo deciso di realizzare 
qualcosa di nuovo e molto semplice, ovvero l'aggiunta di un'animazione nelle transazioni tra le diverse 
activity. Per tarlo è sufficiente utilizzare il seguente metodo: 

public void overridePendingTransition ( int enterAnim, int exitAnim) 

il quale può essere invocato dubito dopo uno startActivity ( ) o un finish ( ) specificando gli 
identificatori delle animazioni di ingresso e di uscita. Nell'ultima versione della piattaforma disponibile 
al momento, Jelly Bean, è stata aggiunta la possibilità di impostare queste informazioni in un oggetto di 
tipo ActivityOptions che viene poi utilizzato come secondo parametro nel seguente overload del 
metodo startActivity () '. 

public void startActivity (Intent intent, Bundle options) 

L'applicazione non può utilizzare questo nuovo metodo in quanto deve supportare anche le versioni 
vecchie della piattaforma, per cui abbiamo usato questa istruzione in diversi punti con alcune delle 
animazioni standard associate alle costanti 

android . R. anìm . f ade_in 
android . R. anìm . f ade_out 
android . R. anìm . slide_in_lef t 
android . R. anìm . slide_out_right 

Lasciamo al lettore l'esercizio della creazione di nuove animazioni e il loro utilizzo con il semplice 
metodo descritto sopra. 

Conclusioni 

In questo capitolo abbiamo studiato gli strumenti che Android offre per la gestione delle animazioni 
Abbiamo visto inizialmente il framework Property Animator, il quale però è disponibile solamente 
dalla versione 3.0 della piattaforma, per poi concentrarci sul framework esistente anche nelle versioni 
precedenti, che abbiamo definito legacy. 
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Capitolo 12 



Realizzazione di widget 



Come è facile constatare osservando le varie pubblicità, gli ultimi dispositivi lanciati sul mercato 
sono caratterizzati da processori molto potenti uniti a display con risoluzioni fino a qualche anno fa 
impensabili Anche per questo motivo sta assumendo sempre più importanza una particolare 
applicazione che abbiamo già incontrato nei capitoli iniziali e che si chiama Home. Essa contiene tutto 
ciò che l'utente vede non appena rivolge lo sguardo verso il proprio smartphone. L'importanza di 
questa applicazione è stata percepita da subito, e infatti proprio dalla versione 1.5 della piattaforma vi 
è la possibilità di creare quelli che si chiamano widget. Si tratta sostanzialmente di "estensioni" che 
una particolare applicazione regala alla Home per poter visualizzare parte delle informazioni che 
l'applicazione stessa gestisce. Nelle ultime versioni della piattaforma sono state poi create delle API 
che permettono di utilizzare le view e Remoteviews in modo interessante. 

Gli App Widget 

Come sappiamo la Home di un dispositivo, ovvero la schermata iniziale o di default, rappresenta il 
punto di accesso verso tutte le applicazioni. Per aumentare l'interattività della Home, ma lo stesso 
vale per qualunque altra activity, dalla versione 1 .5 dell'ambiente esiste la possibilità di integrare parti 
di applicazioni diverse gestendo in modo automatico l'aggiornamento delle informazioni in essi 
visualizzate. Possiamo, per esempio, aggiungere alla Home un componente per la visualizzazione di 
informazioni relative a dei titoli di Borsa o a risultati sportivi, e vederli aggiornare in tempo reale. 

Come vedremo nel dettaglio, il componente che viene inserito all'interno di un altro viene gestito 
attraverso quello che si chiama App Widget Provider, mentre un qualunque componente in grado di 
contenerne un altro si chiama App Widget Host. Sarà poi interessante vedere come un App Widget 
Provider non sia altro che una particolare specializzazione di un BroadcastReceiver in grado di 
ricevere eventi relativi alla sua configurazione, installazione e aggiornamento. Per fare un'analogia con 
un classico pattern MVC possiamo dire che YApp Widget è la view a cui viene associato un modello 
descritto da xmApp Widget Provider. Sulla view potremo eseguire diverse azioni, che verranno da 
questo intercettate e notificate al particolare provider che le gestirà in modo opportuno. Per realizzare 
un App Widget, che da ora chiameremo semplicemente "widget", è sufficiente attenersi ai seguenti 
passi 

1 . Realizzare il layout del widget. 

2. Realizzare YApp Widget Provider, il quale riceverà delle informazioni attraverso degli eventi di 
broadcast eseguendo le azioni associate. 

3 . Configurare un insieme di metadati relativi al layout da utilizzare, la frequenza di aggiornamento 
delle informazioni e il modello (provider) associato. 

4. Definire il widget nel file AndroidManif est . xml. 

5 . Realizzare l'eventuale activity di configurazione del widget. 

Come esempio nella realizzazione di questo tipo di componenti vogliamo aggiungere alla nostra 
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applicazione UGHO un semplice widget che permetta la visualizzazione dell'ultima informazione 
inserita. Nel caso in cui questa non fosse disponibile, visualizzeremo un messaggio che consenta 
all'utente di rientrare nell'applicazione e fornire il proprio "stato d'animo". 

Creazione del layout 

Una parte fondamentale di un widget è rappresentata dalla sua interfaccia, ovvero da quella che 
abbiamo precedentemente associato alla view in un'architettura MVC. A questo proposito non è 
possibile utilizzare un layout qualunque, in quanto si è vincolati all'utilizzo di una Remoteviews da una 
parte e a un insieme di regole di stile dall'altra. Un widget è infatti una view creata da un'applicazione 
ma visualizzata da un'altra in esecuzione in un proprio processo per cui, come avevamo visto nel caso 
delle notifiche, si deve utilizzare una particolare view che sappiamo chiamarsi Remoteviews. Questa 
non può contenere qualunque altra specializzazione di view ma solamente i seguenti componenti: 

• LinearLayout 

• FrameLayout 

• RelativeLayout 

come layout e i seguenti 

• AnalogClock 

• Button 

• Chronometer 

• ImageButton 

• ImageView 

• ProgressBar 

• TextView 

• ViewFlipper 

• ListView 

• GridView 

• StackView 

• AdapterViewFlipper 

come semplici controE È importante sottolineare come eventuali specializzazioni di questi layout o 
controlli non siano supportate. Il primo vincolo è relativo al tipo di componenti da utilizzare, mentre il 
secondo riguarda le dimensioni e lo sfondo che è possibile usare, di cui il lettore potrà trovare 
maggiori informazioni nella documentazione ufficiale di Android. Nel nostro caso creiamo un semplice 
layout definito nel file test_appwidget_iayout . xml nella relativa cartella delle risorse: 

<?xml version="l . 0" encoding="utf-8" ?> 

<RelativeLayout xmlns : android="http : / / schemas . android . com/apk/ res/android" 
android : orientation="vertical" android : layout_width="match_parent " 
android : layout_height="wrap_content " > 
<ImageView 

android: layout_width=" @dimen/widget_image_width" 
android: layout_height=" @dimen/widget_image_height " 
android: padding=" 4dp " 
android : id= " @ + id/ widget_sign_image " 
android : src=" @drawable/sign_leo" 
android : layout_gravity=" lef t | center_vert ical "/> 
<FrameLayout 

android : layout_width="match_parent " 
android : layout_height="wrap_content " 
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android: layout_alignParentRight="true" 

android: layout_toRightOf =" @+id/widget_sign_image"> 

<Button 

android: layout_width="match_parent " 
android: layout_height="wrap_content " 
android: lay out_gr avi ty=" cent er_verti cai" 
android: text=" @string/widget_insert_button_label" 
android: id=" @+id/widget_insert_button" /> 
<include 

android: id="@+id/widget_data" 
android: visibility="gone" 
android: clickable="true" 
layout= " @ layout / custom_list_item" / > 



Si tratta di un layout che contiene a sinistra un' imageview con il proprio segno zodiacale e sulla 
destra qualcosa che dipenderà dalla presenza o meno del dato da noi inserito. Nel primo caso 
visualizzeremo una pulsante come nella Figura 12.1. 



Figura 12.1 II layout del widget quando il dato non è presente 

Nel caso in cui i dati fossero già disponibili per la data corrente, il layout sarà quello che possiamo 
dedurre dalla Figura 12.2. 



</FrameLayout> 
</RelativeLayout> 





Insert your feelings 
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Love : 5 
Health: 2 
Work : 4 
Luck : 3 



Figura 12.2 II layout del widget quando il dato è già stato inserito. 

Come novità nella definizione di questo layout abbiamo l'utilizzo dell'elemento |inoiude/>, il 
quale permette di importare un frammento di layout contenuto in un altro file specificandone però un 
nuovo valore come identificatore. 

NOTA 

In questi layout notiamo la presenza dell' ActionBar ma solamente perché creati all'interno della 
preview di Android Studio. Quando visualizzati nella Home verrà visualizzata solo la nostra parte di 
layout. 

Vedremo quindi come, in base alla disponibilità o meno di dati, sia possibile visualizzare una 
versione o la successiva. Questo è il motivo della presenza di un FrameLayout nella parte destra. 



Definizione dell' App Widget Provider 

L'aspetto più importante di un widget è quello relativo alla sua logica, ovvero al reperimento e alla 
visualizzazione delle informazioni che lo caratterizzano. Tutto questo va definito all'interno di una 
particolare specializzazione della classe AppWidgetProvider del package android. appwidget. Come 
sottolinea la stessa documentazione ufficiale, si tratta di una classe di convenienza, ovvero di una 
particolare specializzazione della classe IroadcastReceìver che, all'interno del metodo 
onReceive ( ) , esegue un test sul particolare tipo di intent ricevuto delegandone l'elaborazione ad altri 
metodi, che andiamo a esaminare nel dettaglio. 

NOTA 

La logica che un A PP wìdgetProvider aggiunge a quella di BroadcastReceiver assomiglia molto a quella di 
una Httpserviet e dei relativi metodi come doceto e doPosto delle sue specializzazioni. Di quest'ultima, 
in quanto servlet, il container invoca sempre il metodo sericeo indipendentemente dal metodo http 
utilizzato. È l'implementazione di serviceli che, in base al metodo http contenuto nella request, 
esegue il dispatching ai relativi metodi doxxxo associati. Nel caso dell' A PP widgetProvìder succede lo 



stesso, solamente che il metodo onReceiveo ricevere un intent e in base al tipo particolare ne delega 
l'elaborazione a un metodo diverso. Come nel caso dell' Htt P serviet è possibile eseguire Yoverhde del 
singolo metodo doxxxo di interesse, anche se qui si possono gestire solo alcuni degli eventi 
associati facendo \'override esclusivamente dei metodi corrispondenti. 

Le operazioni che vengono invocate sulla nostra specializzazione di AppwidgetProvider sono 
quelle relative al particolare evento legato al ciclo di vita deiwidget. Nel momento in cui un widget 
viene installato nella Home per la prima volta, viene invocato sul corrispondente AppwidgetProvider li 
seguente metodo: 

public void onEnabled (Context context) 

Notiamo come il parametro passato sia un riferimento a Context. Anche alla luce di quanto detto 
nella nota precedente, si tratta del metodo che viene invocato dall'implementazione standard di 
onReceive ( ) nel caso in cui si riceva un intent con action corrispondente alla costante statica 
action_appwidget_enabled della classe AppwidgetManager. È un metodo di callback invocato con la 
creazione della prima istanza del widget, in cui potremmo eseguire tutte le eventuali operazioni di 
inizializzazione come la creazione di un DB o la scrittura di un file. 

Quando una o più istanze di un widget associato a un AppwidgetProvider vengono cancellate, 
Fintent generato ha action pari alla costante action_appwidget_deleted della classe 
AppwidgetManager, a cui corrisponde l'invocazione di questo metodo di callback: 

public void onDeleted (Context context, int [ ] appWidgetlds) 

I parametri passati sono un riferimento al Context e un array di identificatori delle istanze che sono 
state cancellate. Questo consente di eseguire alcune operazioni di eliminazione delle risorse a essi 
associate. 

Quando anche fultima istanza del widget viene cancellata viene invece generato un intent associato 
all'action action_appwidget_disabled della classe AppwidgetManager e invocato il metodo: 

public void onDisabled (Context context) 

all'interno del quale inseriremo la logica di rilascio delle risorse utilizzate da tutte le istanze e non 
associate alle singole. 

Nelle ultime versioni di Andro id sono state poi aggiunte delle API per la gestione di App Widget 
"resizable", ovvero di cui è possibile modificare le dimensioni. Il metodo chiamato è il seguente 

public void onAppWidgetOptionsChanged (Context context, 

AppwidgetManager appWidgetManager , int appWidgetld, Bundle newOptions) 

e corrisponde all'invio di un intent associato, per l'action, alla costante 
action_appwidget_dptions_changed. Viene invocato la prima volta che il widget è stato aggiunto alla 
Home e ogni volta che lo stesso subisce delle operazioni di resize. 

Quelli descritti sono i metodi di callback associati al ciclo di vita di un widget in relazione alla sua 
installazione e rimozione. Come vedremo nel paragrafo successivo, a ciascun tipo di App Widget è 
possibile associare una frequenza di aggiornamento che permette, in sintesi, di generare degli eventi di 
broadcast in occasione dei quali ciascun AppwidgetProvider dovrà aggiornare le informazioni a esso 
associate. In questo caso l'operazione di callback invocata sarà 

public void onUpdate (Context context, AppwidgetManager appWidgetManager, int [ ] 
appWidgetlds ) 

e sarà associata all'intent di action corrispondente alla costante action_appwidget_update sempre 
di AppwidgetManager. E un metodo che viene invocato all'installazione di ciascuna istanza di App 
Widget e a intervalli regolari di cui specificheremo la durata. 

In questo caso, oltre all'immancabile Context, vengono passati un riferimento a un oggetto di tipo 
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AppwidgetManager e l'array degli identificatori delle istanze installate. Osservando la documentazione 
vediamo come l'oggetto di tipo AppwidgetManager non sia altro che una specie di registry di tutti i 
provider installati oltre che delle istanze di widget presenti; contiene gli strumenti per interagire con le 
singole istanze di App Widget dato il loro id o specificando il provider corrispondente. All'interno di 
questo metodo inseriremo la logica di aggiornamento della RemoteViews associata al particolare App 
Widget. 

Un aspetto fondamentale da tenere in considerazione è che un provider resta in vita, in quanto 
specializzazione diBroadcastReceiver, per il solo tempo necessario all'esecuzione del suo metodo 
onReceive ( ) . E quindi di fondamentale importanza che l'esecuzione avvenga velocemente per non 
generare un noto errore Application Not Responding (ANR). 

NOTA 

Ricordiamo che si tratta di un errore che vene notificato, attraverso un'opportuna finestra di dialogo, 
in due casi particolari: quando non c'è una risposta a una selezione di un pulsante entro 5 secondi 
oppure quando il metodo onReceive » di un BroadcastReceiver non termina entro 10 secondi. 

Per questo motivo, a meno che non si tratti di operazioni molto brevi e semplici, all'interno del 
metodo onupdate ( ) si ha l'avvio di un service che aggiorna la view associata aWApp Widget in modo 
asincrono. Questo è proprio l'approccio che abbiamo utilizzato nel nostro esempio, di cui alleghiamo 
il codice: 

public class UghoAppWidgetProvider extends AppWidgetProvider { 

private static final long MILLIS_IN_DAY = 1000L * 3600 * 24; 

public void onUpdate (Context context, AppwidgetManager appWidgetManager, 
int[] appWidgetlds) { 
for (int i = 0; i < appWidgetlds . length; i++) { 
Intent updatelntent = new Intent (context, 

UpdateUghoWidgetService . class) ; 
update Intent 

.putExtra (AppwidgetManager .EXTRA_APPWIDGET_ID, appWidgetlds [i] ) ; 
context . startService (updatelntent) ; 

} 

} 

public static class UpdateUghoWidgetService extends Service { 

public int onStartCommand ( Intent intent, int flags, int startld) { 
Bundle extras = intent . getExtras () ; 
int mAppWidgetld = 0; 
if (extras != nuli) { 

mAppWidgetld = extras 

. get Int (AppwidgetManager . EXTRA_APPWIDGET_ID , 
AppwidgetManager . INVALID_APPWIDGET_ID) ; 

} 

RemoteViews remoteView = new RemoteViews (getPackageName () , 

R. layout . widget_layout ) ; 

final long now = System. currentTimeMillis () ; 

final long today = now - (now % MILLIS_IN_DAY) ; 

final String where = UghoDB . HoroVote . ENTRY_DATE + " = ?"; 

final Stringi] whereArgs = new String []{ String . valueOf (today )} ; 

Cursor data = getContentResolver ( ) 

. query (UghoDB . HoroVote . CONTENT_URI , nuli, where, 

whereArgs, nuli); 
if (data .moveToNext () ) { 

remoteView. set ViewVisibility (R. id. widget_insert_button, 
View.VISIBLE) ; 

remoteView. setViewVisibility (R. id. widget_data, View.GONE) ; 
showData (remoteView, data, mAppWidgetld); 

} else { 
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remoteView. setViewVisibility (R. id.widget_insert_button, 
View.GONE) ; 

remoteView. setViewVisibility (R. id.widget_data, View. VISIBLE) ; 

} 

final Intent newDatalntent = new Intent(this, 

NewDataActivity. class) ; 
final Pendinglntent newDataPendinglntent = 

Pendinglntent . getActivity (this , 0 , newDatalntent , 

Pendinglntent . FLAG_UPDATE_CURRENT) ; 
remoteView . setOnClickPendinglntent (R . id . widget_insert_button , 

newDataPendinglntent) ; 
final Intent listDatalntent = new Intent (this, 

InputDataActivity. class) ; 
final Pendinglntent listDataPendinglntent = 

Pendinglntent . getActivity (this, 0, listDatalntent, 

Pendinglntent. FLAG_UPDATE_CURRENT) ; 
remoteView. setOnClickPendinglntent (R. id. widget_data, 

listDataPendinglntent) ; 
data . close ( ) ; 

AppWidgetManager manager = AppWidget Manager .getlnstance (this) ; 
manager . updateAppWidget (mAppWidgetld, remoteView) ; 

return Service . START_STICKY; 

} 

public IBinder onBind ( Intent intent) { 
return nuli; 

} 

} 

} 

Vediamo come in corrispondenza del metodo onupdate ( ) venga avviato un servizio attraverso un 
intent nei cui extra è stato inserito il riferimento alla particolare istanza da aggiornare. Abbiamo scelto 
di avviare un servizio per istanza in quanto successivamente vedremo come gestire in modo 
automatico diverse frequenze di aggiornamento. All'interno del servizio vi è quindi la creazione e 
aggiornamento della Remoteviews associata a ciascuna istanza. È interessante notare come questo sia 
reso possibile attraverso il metodo updateAppWidget o della classe AppWidgetManager di cui abbiamo 
ottenuto precedentemente un'istanza. Il nostro esempio è molto semplice e l'operazione eseguita 
all'interno del servizio non è molto dispendiosa in termini di risorse e tempo. Quello descritto è 
comunque un ottimo modello da utilizzare nel caso in cui le operazioni da eseguire fossero più 
impegnative, come per esempio un accesso alla Rete attraverso un Httpciient. Altra considerazione 
interessante riguarda l'utilizzo del metodo setViewVisibility o per la modifica dello stato di visibilità 
di un elemento della RemoteViews. In questo caso non dobbiamo infatti ottenere alcun riferimento agli 
elementi della UI, ma utilizzare dei metodi del tipo set ( ) per impostare alcune proprietà sugli elementi 

di RemoteViews. 

La classe RemoteViews CI fornisce anche metodi di utilità per la gestione degli eventi. Nel nostro 
caso abbiamo infatti la necessità di associare eventi diversi al pulsante o alla lista dei voti nelle due 
situazioni descritte. Per farlo abbiamo semplicemente creato due diversi p endinglntent che ci 
permetteranno di lanciare le relative activity. Per collegare il lancio degli intent all'evento del clic su un 
componente abbiamo utilizzato il metodo 

public void setOnClickPendinglntent (int viewld, Pendinglntent pendinglntent) 

Abbiamo così impostato intent, e quindi p endinglntent, diversi ai due componenti. 
Prima di proseguire facciamo una considerazione sulla registrazione del servizio nel file 
AndroidManifest .xml. Avendolo descritto attraverso una classe interna statica, il nome generato dal 

compilatore della relativa classe è ughoAppwidgetProvider$updateughowidgetservice, e quello 
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dovrà essere iutilizzato per la sua registrazione: 

<service andrò id : name=" . appwidget . UghoAppWidgetProvider $UpdateUghoWidget Service " /> 

Impostazione dei metadati 

Dopo aver realizzato il layout del widget e averne descritto la logica di aggiornamento dei dati, è 
necessario specificare un insieme di metadati le cui informazioni sono incapsulate in un oggetto di tipo 
AppwidgetProviderinfo. La modalità più semplice per definire queste informazioni prevede la 
creazione di un documento XML da inserire nella cartella /res/xml delle risorse, che nel nostro caso 
abbiamo chiamato app_widget_conf .xml e che riportiamo di seguito: 

<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

<appwidget-provider xmlns : android="http : / / schemas . android. com/ apk/ res/android" 

android:min android:min 

android : updatePeriodMillis=" 8 64 00000" 

android: inìtialLayout="@ layout /widget_layout " 

android: resizeMode="horìzontal I vertical" 

android : widget Category="home_screen | keyguard"> 
</ appwidget-provider> 

Irmnzitutto questo documento ci consente, attraverso gli attributi android :minwidth e 
android :minHeight, di impostare le dimensioni che il widget occuperà di default non appena verrà 
inserita all'interno della Home. Si noti che la maggior parte dei dispositivi suddivide la Home in alcuni 
rettangoli (celle) che rappresentano anche un punto di riferimento per il posizionamento del widget. 
Sebbene non sia mai vantaggioso utilizzare dei widget di dimensioni maggiori di 4x4 celle, le 
dimensioni effettive sono quelle che meglio si adattano alla Home. 

Uno degli attributi più importanti è android : updatePeriodMìll is, che ci permette di indicare il 
tempo minimo di refresh delle informazioni. Relativamente a questo attributo è bene fare alcune 
precisazioni. La prima è che si tratta di un'informazione comune a tutti gli App Widget associati a un 
particolare provider. La seconda, molto importante, è che dalla versione 1.6 dell'ambiente si tratta di 
un parametro che può avere come valore mimmo quello corrispondente a 30 minuti. È un 
accorgimento che è stato imposto al fine di limitare al massimo lo spreco delle risorse massimizzando 
la durata della batteria. Sebbene nei dispositivi reali sia una grandezza accettabile, diventa un 
problema in caso di debug delle applicazioni. Ricordiamo comunque che il metodo update ( ) non 
viene eseguito solamente nei tempi configurati attraverso l'attributo updatePeriodMiiiis ma anche in 
corrispondenza dell'installazione di una nuova istanza o comunque a seguito del lancio di un intent a 
cui è associata l'action action_appwidget_update. In questo file di configurazione si può impostare il 
documento di layout del widget attraverso l'attributo di nome android: initiaiLayout. Dalla versione 
3.0 dell'ambiente è poi possibile poi specificare un'immagine come preview deWApp Widget 
attraverso l'attributo android :previewimage. Si tratta dell'immagine che viene visualizzata nel 
momento in cui si sceglie il widget dal menu di quelli disponibili; dovrà essere quindi un'immagine che 
descrive il widget stesso dando un'indicazione di quello che sarà il risultato. A questo proposito 
l'emulatore fornisce un'applicazione che consente di generare l'immagine di preview direttamente dal 
widget. Al momento lasciamo tale attributo vuoto per poi valorizzarlo successivamente. 

Una delle novità dell'ultima versione è rappresentata dalla possibilità di eseguire il resize del widget. 
Per questo motivo sono ora disponibili tre nuovi attributi II primo si chiama android: resìzeMode e 
descrive le regole secondo cui un widget può essere modificato nelle dimensioni una volta aggiunto 
nella Home. I valori sono dati da horizontai e vertical. La dimensione può essere infatti modificata 
in larghezza, altezza oppure in entrambe le direzioni. Gli altri due attributi sono 
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android:minResizeHeight e android:minResizewidth e rappresentano rispettivamente l'altezza e la 
larghezza minime acuiun widget può essere ridimensionato; garantiscono che il widget non assuma 
dimensioni che lo rendono inutilizzabile. 
NOTA 

In precedenza abbiamo menzionato gli attributi minWìdth © minHeight. La regola generale prevede siano 
presi i valori minimi tra quelli del tipo minxx e quelli minResizexx. Nel caso il resize non sia abilitato, 
verranno considerati solamente quelli del tipo minxx. 

Nel nostro esempio abbiamo tatto in modo che il widget possa essere modificato in entrambe le 
dimensioni con un valore minimo di 72 dp. 

Definizione dell' App Widget nel Manifest 

A questo punto non ci resta che definire i diversi componenti nelT AndroidManif est . xml e testarne 
il funzionamento. Come accennato in precedenza, si tratta di definire uni roadcastReoeiver m grado 
di ricevere eventi rappresentati da intent con un'action specifica. In particolare nel nostro caso 
abbiamo aggiunto questa definizione: 

<receiver android: name=" . appwidget . UghoAppWidget Provider "> 
<intent-f ilter> 

<action android : name=" android . appwidget . action . APPWIDGET_UPDATE" /> 
</intent-f ilter> 

<meta-data android : name= " android . appwidget . provider " 
android : resource=" @xml/ app_widget_conf " /> 

</reoeiver> 
<service 

android : name= " . appwidget . UghoAppWidgetProvider $UpdateUghoWidgetService "/> 

Notiamo come sia fondamentale specificare come action dell'intent associato quella definita dal 
valore android . appwidget . action . appwidget_update al fine di ricevere gli eventi di aggiornamento. 
Vediamo poi come il riferimento al file XML di configurazione venga specificato attraverso un 
elemento <meta-data/> associato al nome android. appwidget .provider. Infine abbiamo la 
definizione del servizio di aggiornamento che ricordiamo essere descritto da una classe interna. Non ci 
resta quindi che testare il nostro widget. Innanzitutto dobbiamo eseguire l'applicazione almeno una 
volta in modo da installare il widget tra quelli disponibili II passo successivo consiste nell'andare nella 
sezione relativa ai widget, la quale dipende dal tipo di interfaccia del dispositivo. In unNexus 4 si 
seleziona il pulsante di accesso all'elenco delle applicazioni e poi la scheda corrispondente ai widget. 
Proseguendo in fondo alla lista si ottiene quanto mostrato nella Figura 12.3. 
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1 I A A 

APPLICAZIONI WIDGET 




Figura 12.3 Selezione del widget nell'elenco di quelli disponibili. 

Il nostro widget è stato aggiunto all'elenco di tutti quelli disponibili. A questo punto trasciniamo il 
widget in una delle pagine libere dalla Home: otteniamo il brutto risultato nella Figura 12.4. 
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Figura 12.4 Primo tentativo di visualizzazione del nostro widget. 

I problemi sono di due tipi II primo riguarda la mancanza di uno sfondo che in qualche modo 
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delinei i contorni del widget. Il secondo è relativo alle dimensioni, che nel nostro caso sono quadrate e 
interamente occupate dall'immagine. Il problema sta quindi nelle dimensioni iniziali del widget e nella 
sua capacità di resize. Se infatti eseguiamo un evento di long click sul widget lo stesso diventa 
ridimensionabile. Allargandolo in modo da occupare due delle celle nella Home il risultato è quello 
nella Figura 12.5. 




Figura 12.5 II widget viene allargato. 



Per quello che riguarda lo sfondo è sufficiente andare all'indirizzo 

http : //developer . android . com/guide/practices/ui_guidelines/widget_design . html #t empi ates 

e scaricare quello che si chiama App Widget Template Pack, che contiene un insieme di immagini del 
tipo NinePatch da utilizzare come sfondo. Si tratta di un archivio che contiene tutta una serie di risorse 
Drawable che ci vengono in aiuto. Nel nostro caso abbiamo copiato le risorse nelle relative 
corrispondenti e impostato il layout 

android: background= "@drawable/appwidget_bg" 

nel nostro documento di layout di nome widget_layout . xml. Il secondo problema si risolve invece 
a livello di file di configurazione, ovvero: 

<?xml version="l . 0" encoding="utf-8 " ?> 

Oppwidget-provider xmlns : android="http : / / schemas . android. com/ apk/ res/ android" 
android : min android : min 
android : updatePeriodMillis=" 8 64 00000" 
android : initialLayout="@ layout /widget_layout " 
android: resizeMode="vertical" 

android: widget Category="home_screen | keyguard"> 
</appwidget-provider> 

La modifica nel file di configurazione e dello sfondo nel layout porta al risultato nella Figura 12.6, 
che è sicuramente più accettabile. 
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Figura 12.6 Aggiunta del nostro widget alla Home del dispositivo. 

A questo punto facciamo un test che ci permetterà di evidenziare un problema a cui daremo 
soluzione. Aggiungiamo un widget che, nel caso in cui non vi fossero i dati per il giorno corrente, sarà 
quello della Figura 12.7. 



Collegato come dispositivo multimediale 




Figura 12.7 II widget quando non è stata inserita la data per il giorno corrente. 

Se selezioniamo ora il pulsante, andiamo all'attività descritta dalla classe NewDataActivity per 
l'inserimento delle info richieste. Si tratta infatti dell'activity impostata in fase di creazione della 
RemoteViews nel nostro servizio. Immettiamo le informazioni richieste dopodiché l'activity termina e si 
ritorna alla Home, dove però le informazioni non sono aggiornate. Per come abbiamo impostato il 
nostro widget, esso si aggiornerà dopo un periodo di tempo paria quanto specificato nell'attributo 
android : updatePeriodMill is nel file di configurazione app_widget_conf .xml, ovvero ogni 
86.400.000 millisecondi, che corrispondono a un giorno. Abbiamo quindi bisogno di forzare 
l'aggiornamento nel momento in cui viene inserito un nuovo dato. Per farlo si utilizza ilwidgetManager, 
il quale però ci fornisce diverse alternative. Nel caso in cui disponessimo dell'identificatore della 
particolare istanza di widget, è possibile forzarne l'aggiornamento. Nel caso in cui questa 
informazione non fosse disponibile dobbiamo necessariamente forzare l'update di tutte le istanze 
presenti. Nel prossimo paragrafo vedremo il caso in cui l' informazione viene automaticamente inserita 
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come extra di un intent lanciato dal widget. Nel caso in cui arrivassimo dal pulsante nel widget la 
responsabilità sarebbe nostra, per cui aggiungeremo F informazione come extra associandola alla 
chiave 

AppWidgetManager . EXTRA_APPWIDGET_ID 

Nella creazione deipendingintent da lanciare dal nostro widget dovremo aggiungere la riga di 
codice qui evidenziata: 

final Intent newDatalntent = new Intent (this, NewDataActivity . class ) ; 
newDatalntent . putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID , mAppWidgetld) ; 

final Pendinglntent newDataPendinglntent = Pendinglntent . getActivity (this, 0, 
newDatalntent, Pendinglntent . FLAG_UPDATE_CURRENT) ; 

A questo punto la nostra activity di inserimento del nostro umore dovrà in qualche modo capire da 
chi è stata chiamata e quindi verificare se rinformazione relativa all'id del widget è presente oppure 
no. Invitiamo il lettore a consultare il codice delle classi NewDataActivity e del relativo fragment di 
nome NewDataFragment. Neli'activity andiamo a leggere l'eventuale valore relativo alwidgetid 
attraverso le seguenti righe di codice: 

Intent intent = getlntent ( ) ; 
Bundle extras = intent . getExtras () ; 
if (extras != nuli) { 

mAppWidgetld = extras . getlnt ( 

AppWidgetManager .EXTRA_APPWIDGET_ID, 

AppWidgetManager . INVALID_APPWIDGET_ID) ; 

} 

Sappiamo infatti che, se presente, l'identificatore è contenuto nell'extra che abbiamo valorizzato in 
precedenza. Ora si tratta di utilizzare questa informazione nel momento in cui salviamo il dato, ovvero 
nel metodo additemi ) del fragment, il quale ha ottenuto l'eventuale widget id attraverso l'interfaccia 
di callback di comunicazione con l'activity che lo contiene. Facciamo attenzione al seguente codice: 

final AppWidgetManager appWìdgetManager = 

AppWidgetManager . getlnstance (getActivity ( ) ) ; 
final int widgetToUpdate = mListener . getAppWidgetld ( ) ; 
if (widgetToUpdate >= 0) { 

Intent updateWidgetlntent = new Intent () ; 

updateWidgetlntent . setAction (AppWidgetManager . ACTION_APPWIDGET_UPDATE) ; 
updateWidgetlntent . putExtra (AppWidgetManager . EXTRA_APPWIDGET_IDS , 

new int [] {widgetToUpdate}) ; 
Uri updateUri = Uri . withAppendedPath ( 

Uri . parse ( "customappwidget : //widget/id/ " ) , 
String . valueOf (widgetToUpdate) ) ; 
updateWidgetlntent . setData (updateUri) ; 
getActivity () . sendBroadcast (updateWidgetlntent) ; 

} 

Innanzitutto abbiamo ottenuto un riferimento all'oggetto AppWidgetManager, che sappiamo essere la 
nostra interfaccia verso tutti i widget installati Nel caso in cui sia presente l'identificatore, dobbiamo 
lanciare un intent che forzi l'update del corrispondente widget. Come abbiamo visto, si deve attivare 
un BroadcastReceiver, per cui dovremo creare un intent opportuno da lanciare con il metodo 
sendBroadcast ( ) . La prima informazione è alquanto ovvia: è l'action associata alla costante 
action_appwidget_update. È un'informazione che non è sufficiente inquanto si vuole anche l'insieme 
degli identificatori dei widget da aggiornare. Per farlo si utilizza un extra di nome 
AppWidgetManager . extra_appwidget_ids, il cui valore è un array di interi che nel nostro caso 
contiene il solo identificatore del widget a nostra disposizione. La parte successiva è molto 
interessante in quanto è quella che ci permette di non inviare F intent a tutti i widget installati nel 
dispositivo anche da parte di applicazioni diverse. Come più volte sottolineato, gli extra non vengono 
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considerati nel processo di intent resolution per cui serve qualcosa che ci permetta di restringere il 
campo, ovvero il tipo di dati. Per questo motivo abbiamo definito un URI di questo tipo: 

customappwidget : / / widget/ id/<widgetld> 

In questo modo, grazie alle regole di intent resolution, risponderanno solamente quei componenti in 
grado di soddistàre il tipo di dato corrispondente. Per questo motivo si renderà necessaria la seguente 
aggiunta nel file di configurazione AndroidManif est . xml: 

<receiver android: name=" . appwidget . UghoAppWidget Provider "> 
<intent-f ilter> 

<action android: name=" android. appwidget . action . APPWIDGET_UPDATE"/> 
</intent-f ilter> 
<intent-f ilter> 

<action android : name=" android . appwidget . action . APPWIDGET_UPDATE" /> 
<data android : scheme= " customappwidget " /> 
</intent-f ilter> 

<meta-data android: name=" android . appwidget .provider" 

android : resource=" @xml /app_widget_conf " /> 
</ receiver> 

L'action dovrà essere la stessa ma in più avremo la definizione del campo <data/> per lo schema 
da noi definito al momento del lancio dell' intent. 

Il lettore potrebbe suggerire di abbassare il tempo di refresh del widget in modo che lo stesso si 
aggiornasse in modo più veloce. Questa soluzione non va bene. Da un lato questo provocherebbe un 
numero elevato di intent che stresserebbero il sistema in modo inutile e con conseguente consumo 
eccessivo di batteria. Il secondo motivo è che non è possibile specificare per l'attributo 
android : updatePeriodMillis Utl valore inferiore ai 30 minuti Questo proprio per la natura stessa dei 
widget. 

Realizzazione di activity di amministrazione 

Come già accennato, la precedente realizzazione di widget ha come lacuna quella di non consentire 
la personalizzazione delle relative informazioni. In generale le personalizzazioni di un widget possono 
essere moltissime. Un'applicazione che visualizza lo stato del meteo potrebbe permettere la selezione 
della città. Un'altra applicazione per la visualizzazione dei risultato del campionato di calcio potrebbe 
permettere la selezione della partita. Nel nostro caso non esiste questa grande libertà, per cui 
permettiamo solamente la selezione del colore del testo. 

NOTA 

Si tratta di un esempio di proprietà che è legato alla particolare istanza del widget. Sta alla 
particolare applicazione e alla fantasia del lettore decidere quale di queste proprietà rendere 
effettivamente editabili. 

Di solito l'editing delle informazioni di una particolare istanza di widget avviene all'interno di una 
schermata molto simile a quella dei Settings. Nel nostro caso realizziamo invece un' activity molto 
semplice che consentirà di scegliere il colore del testo tra tre valori; quello che ci interessa è infatti la 
modalità di comunicazione con il widgetManager . Per poter integrare la configurazione del widget 
all'interno del suo ciclo di vita, l'ambiente Android ha fissato il valore dell'action a cui questa attività 
dovrà rispondere. La nostra attività di configurazione dovrà rispondere a un intent con action pari a 

android . appwidget . action . APPWIDGET_CONFIGURE 

Nel nostro caso abbiamo realizzato la semplice activity descritta dalla classe 
UghoAppWidget settings ilcuinome, completo di package, va anche specificato nel file di 
configurazione del widget, ovvero in app_widget_conf .xml, attraverso l'attributo di nome 
android : configure. Questo file diventa il seguente (dove siamo andati a capo solo per motivi di 
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spazio): 



<?xml version=" 1 . 0 " encoding="utf-8 " ?> 

Oppwidget-provider xmlns : android="http : / / schemas . android. com/apk/res/ android" 
android:min android : min 
android:updatePeriodMillis="8 64 000 00" 
android : init ialLayout= " @ layout / widget_layout " 
android: conf igure="uk . co .massimocarli . android. ugho . appwidget 

. UghoAppWidgetSettings " 
android: resizeMode="vertical " 

android: widgetCategory="home_screen | keyguard"> 
</ appwidget -provide r> 

Notiamo come il nome dell' activity di configurazione venga specificato tenendo conto anche del 
package di appartenenza. È una configurazione che permette la modifica degli attributi del widget. 
Viene lanciata dall' Appwidget Ho st, la Home in questo caso, nella modalità 
startActivityForResult ( ) aspettandosi da questa un risultato. 

Nel nostro caso l'attività di configurazione è quella nella Figura 12.8, e contiene alcuni pulsanti 
selezionando i quali si può modificare il colore dei testi del nostro widget. 
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Figura 12.8 Activity di configurazione del widget. 



Iniziamo dal metodo oncreate o : 

dOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
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setContentView (R . layout . widget_conf _layout ) ; 
setResult (RESULT_CANCELED) ; 

mPrefs = getSharedPref erences (APP_WIDGET_PREFS, Context .MODE_PRIVATE) ; 
mWidgetld = getwidgetld (getlntent ( ) ) ; 

mOutputView = f indViewByld (R. id.widget_current_color) ; 

final int currentColor = mPref s . getlnt (CURRENT_COLOR_KEY, Color . BLACK) ; 
mOutputView . setBackgroundColor (currentColor) ; 

} 

Un primo aspetto interessante riguarda l'istruzione messa in evidenza, che consente di impostare 
come risultato dell' activity quello identificato dalla costante result_canceled. Questo permette di 
impedire la creazione dell'istanza dell'App Widget nel caso in cui l'utente selezionasse il pulsante 
Back una volta visualizzata l'activity di configurazione. Di seguito vediamo come si utilizzano le note 
API per la gestione delle Pref erences per ottenere l'eventuale valore salvato. A questo proposito 
notiamo come si utilizzi un pattern per la costruzione della chiave associata all'id dell'istanza. Il 
metodo getwidgetld ( ) a cui si là riferimento sia qui sia nel codice che vedremo successivamente, è 
un nostro metodo di utilità che estrae dall' intent ricevuto rinformazione che l'AppwidgetHost inserisce 
come extra relativo all'identificatore dell'istanza che si sta configurando. È qualcosa di molto simile a 
quanto visto nel paragrafo precedente: 

private int getwidgetld ( Intent intent) { 
Bundle extras = intent . getExtras () ; 
int appWìdgetld = 0; 
ìf (extras != nuli) { 

appWidgetld = extras . getlnt (AppWidgetManager . EXTRA_APPWIDGET_ID, 
AppWidgetManager . INVALID_APPWIDGET_ID) ; 

} 

return appWidgetld; 

} 

Ancora una volta tale informazione è associata alla costante extra_appwidget_id negli extra 
dell' intent. In corrispondenza della selezione di impulsante non facciamo altro che eseguire il seguente 
metodo: 

public void changeColor ( final View button) { 
int newColor = 0; 
switch (button . getld () ) { 

case R.id.widget_red_button: 
newColor = Color. RED; 
break; 

case R . id . widget_green_button : 
newColor = Color. GREEN; 
break; 

case R. id.widget_blue_button : 
newColor = Color. BLUE; 
break; 

} 

mOutputView. setBackgroundColor (newColor) ; 
updateRef resh (newColor) ; 

} 

Esso verifica qual è stato il pulsante premuto, imposta il relativo colore e poi invoca il metodo 
updateRef resh o . Si tratta diunmetodo che esegue principalmente tre funzioni: 

• aggiorna le informazioni nelle Pref erences; 

• attiva la notifica degli aggiornamenti attraverso il servizio di alert; 

• notifica all'AppwidgetHost la conclusione dell'editing. 

La parte del metodo updateRef resh o relativa all'aggiornamento delle informazioni nelle 
Pref erences è il seguente: 

SharedPref erences . Editor editor = mPref s . edìt ( ) ; 
int instanceld = getwidgetld (getlntent ()) ; 
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editor . putlnt (mColorKey, newColor) ; 
editor . commit ( ) ; 

La chiave corrispondente al widget era già stata calcolata nel metodo oncreate ( ) , per cui non 
tacciamo altro che utilizzarla per associarvi il nuovo colore, che è rappresentato da un valore intero. 

Per quello che riguarda la richiesta di aggiornamento al widget corrispondente utilizziamo lo stesso 
meccanismo del paragrafo precedente, ovvero quello che abbiamo implementato attraverso le 
seguenti righe di codice: 

Intent updatelntent = new Intento ; 

updatelntent . setAction (AppWidgetManager . ACTION_APPWIDGET_UPDATE) ; 
updatelntent .putExtra (AppWidgetManager . EXTRA_APPWIDGET_IDS, 

new int []{ instanceld} ) ; 
Uri updateUri = Uri . withAppendedPath (Uri 

.parse ( "customappwidget : / /widget/ id/ " ) , String . valueOf (instanceld) ) ; 
updatelntent . setData (updateUri) ; 
sendBroadcast (updatelntent) ; 

che abbiamo già spiegato in precedenza. L'ultimo passo riguarda la notifica del risultato attraverso 
queste poche righe: 

Intent resultValue = new Intento," 
resultValue . putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, instanceld) ; 
setResult (RESULT_OK, resultValue) ; 
finish ( ) ; 

È il classico meccanismo di comunicazione che utilizza il metodo startActivìtyForResuit o e che 
abbiamo descritto più volte nel dettaglio. 

A completamento di quanto illustrato manca ancora un punto fondamentale, ovvero la 
cancellazione delle informazioni nelle impostazioni che deve avvenire quando il widget viene eliminato. 
Per farlo dobbiamo implementare così il metodo onDeietedo nel nostro provider: 

public void onDeleted (Context context, int [ ] appWidgetlds) { 
SharedPref erences config = context 

. get SharedPref erences (UghoAppWidgetSettings . APP_WIDGET_PREFS, 
Context .MODE_PRIVATE) ; 
SharedPref erences . Editor configEditor = conf ig . edit ( ) ; 
for (int i = 0; i < appWidgetlds . length; i++) { 

final String mColorKey = UghoAppWidgetSettings . CURRENT_COLOR_KEY + 

appWidgetlds [i] ; 
configEditor . remove (mColorKey) ; 

} 

configEditor . commit ( ) ; 

super .onDeleted (context, appWidgetlds) ; 

} 

Le istruzioni dovrebbe risultare chiare. Il file di configurazione AndroidManìf est . xml necessita ora 
solamente della definizione dell'attività di configurazione come segue: 

<activity android: name=" . appwidget . UghoAppWidgetSettings "> 
<intent-filter> 

<action android: name=" android. appwidget . action . APPWIDGET_CONFIGURE" /> 
</intent-filter> 
</ activity> 

Non ci resta che lasciare al lettore la verifica del funzionamento di questa versione di App Widget 
che abbiamo completato con la definizione dell'attività di configurazione. Come ultima osservazione 
diciamo che al momento l'attività di configurazione viene lanciata automaticamente in fase di aggiunta 
del widget alla Home, ma potrebbe essere richiamata anche in altri punto lanciando l'intent 
opportuno. 

App Widget e collection 
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In Andro id 3.0 è stata aggiunta la possibilità di creare dei particolari App Widget in grado di 
visualizzare elenchi di informazioni attraverso un layout che può comprendere uno dei seguenti 
componenti: 

• ListView 

• GridView 

• StackView 

• AdapterViewFlipper 

Listview e Gridview sono già noti in quanto trattati in precedenza, mentre la stackview e 
F AdapterViewFlipper sono componenti che permettono di visualizzare delle informazioni attraverso 
un look &feel del tipo nella Figura 12.9. Notiamo infatti la visualizzazione di diverse view una sopra 
l'altra organizzate secondo una struttura a stack. 
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Figura 12.9 Esempio di widget che utilizza una StackView. 

Si tratterà quindi di un App Widget che dovrà interagire in qualche modo con un adapter per 
l'accesso alle informazioni relative alle view corrispondenti ai diversi elementi. Dovrà essere un 
adapter particolare, in quanto gli elementi che è possibile visualizzare dovranno essere delle 
Remoteviews e non delle normali view. A tale scopo è stata creata la classe RemoteViews Service del 
package android . widget, la quale descrive un servizio in grado di fornire ai diversi widget il 
riferimento a una RemoteviewsFactory a cui richiedere le RemoteViews da visualizzare. In pratica la 
realizzazione di un App Widget per la visualizzazione di un insieme di informazioni contenute, per 
esempio, in un content provider prevede i seguenti passi 

1 . Realizzazione del layout dell'App Widget e dei suoi elementi 

2. Creazione di un'implementazione di RemoteViews Servi ce. 

3. Creazione dell' AppWidgetProvider. 

4. Creazione di un'implementazione di RemoteviewsFactory. 

5 . Definizione dei metadati di descrizione deWApp Widget. 

6. Dichiarazione nell' AndroidManif est . xml. 

7. Gestione della selezione degli item 
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Come accennato in precedenza, si tratta di widget che consentono di visualizzare le informazioni 
contenute in un content provider che per fortuna abbiamo già implementato nel Capitolo 8 (dedicato 
alla gestione della persistenza). Prima di procedere dobbiamo ricordare che queste API sono 
disponibili dalla versione 1 1 della piattaforma. Per questo motivo creeremo, per il test, una nuova 
applicazione che chiamiamo loiiectionwidgetTest. Il fatto che questa utilizzi lo stesso content 
provider della precedente non ci deve sorprendere per la natura stessa degli oggetti condivisi dei 
content provider. 

Realizzazione del layout 

Come fatto nell'esempio precedente, il primo passo consiste nella creazione del layout del nostro 
App Widget. In questo caso sarà un layout che contiene imo dei componenti elencati, che qui è una 
stackview. Nel documento di layout che segue, contenuto nel file widget_iist_iayout . xml, 
possiamo notare la presenza anche di ima view da visualizzare nel caso in cui non vi fossero 
informazioni, analogamente a quanto avviene per una Listview quando gestita attraverso la 
ListActivity, anche se qui sarà nostra responsabilità visualizzare una o l'altra: 

<?xml version="l . 0" encoding="utf-8" ?> 

<FrameLayout xmlns : android="http : / /schemas . android . com/ apk/res/android" 

android: layout_width="match_parent " 

android: layout_height="match_parent "> 
<StackView 

android: id="@+id/ stack_view" 

android : layout_width="match_parent " 

android : layout_height="match_parent " 

android: gravity= "center" 

android: loopViews="true" /> 
<TextView 

android : id=" @+id/empty_view" 

android : layout_width="match_parent " 

android: layout_height="match_parent " 

android: gravity="center " 

android : t extColor="@ color /message_text_color" 
android : textStyle="bold" 
android: text=" @string/empty_message" 
android : textSize=" @dimen/message_text_size" /> 
</FrameLayout> 

Da rilevare la presenza dell'attributo android: loopsViews, il quale permette di utilizzare 
un'animazione di layout che consente di visualizzare le varie Remoteviews una alla volta in modo 
automatico. Quello descritto è il layout deWApp Widget ma non quello relativo a ciascun elemento 
che si intende visualizzare; per questi dobbiamo creare un altro documento XML, che nel nostro caso 
è descritto dal file custom_list_item. xml e che abbiamo preso dal progetto UGHO per la 
visualizzazione dell'elemento in una lista. 

Creazione di un'implementazione di Remote ViewsService 

Anche in questo caso il widget ha la necessità di utilizzare un servizio in quanto, come abbiamo già 
visto, l'aggiornamento delle informazioni visualizzate avviene attraverso una specializzazione della 
classe AppWìdget Provider, che a sua volta specializza la classe BroacastReceiver. Per questo 
motivo il compito di questo componente dovrà essere il più snello possibile per non incappare nel 
problema dell' ANR. In questo tipo di widget il servizio dovrà essere una specializzazione della classe 
RemoteviewsService e dovrà quindi implementare l'operazione 

public RemoteViewsFactory onGetViewFactory ( Intent intent) 
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perla creazione dell'oggetto di tipo RemoteviewsFactory che sarà poi il responsabile delle 
creazione della Remoteviews da visualizzare. Nel nostro caso il metodo è così implementato: 

public class CollectionAppProviderService extends RemoteViewsService { 
SOverride 

public RemoteviewsFactory onGetViewFactory ( Intent intent) { 
HoroRemoteViewsFactory vìewsFactory = 

new HoroRemoteViewsFactory (getApplicationContext () , intent); 
return viewsFactory; 

} 

} 

e non fa altro che creare un'istanza della classe HoroRemoteViewsFactory, che descriveremo 
successivamente, come implementazione dell'interfaccia RemoteviewsFactory. I parametri che 
passeremo saranno il riferimento dell' AppiicationContext e dell' intent che avrà attivato il servizio 
stesso e che sarà lanciato dal particolare A PP widgetProvider che descriviamo nel prossimo 
paragrafo. Un'ultima osservazione fondamentale riguarda la modalità con cui questo servizio viene 
descritto nell'AndroidManifest.xmi, ovvero attraverso il seguente elemento: 

<service android: name=" .CollectionAppProviderService" 

android : permission=" android . permission . B IND_REMOTEVI EWS " 

android : exported=" false" /> 

Di fondamentale importanza è la definizione del permesso evidenziato in grassetto, che rappresenta 
il permesso che dovrà possedere il componente che andrà ad attivare il servizio stesso. È bene 
ricordare che se non venisse specificato alcun permesso per l'esecuzione del servizio, il sistema 
considererebbe come necessari quelli dell'omonimo attributo dell'elemento <appiication/>. 
Interessante è anche l'utilizzo dell'attributo android :ex P orted, il quale, come già visto nel Capitolo 9, 
permette di specificare se il servizio può essere utilizzato anche da altre applicazioni 

Creazione dell' AppWidgetProvider 

Una volta creato il servizio, implementiamo il componente che avrà la responsabilità di attivarlo al 
fine di provvedere alla modifica delle Remoteviews. Nel nostro caso abbiamo creato la classe 
coiiectionAppProvider, che ci accingiamo a descrivere nel dettaglio nella sua parte fondamentale 
che, anche per questo App Widget, è rappresentata dal suo metodo onupdate ( ) : 

SOverride 

public void onUpdate (Context context, AppWidgetManager appWìdgetManager , 
int [ ] appWidgetlds) { 
Log.i (TAG_LOG, "Update") ; 

for (int i = 0; i < appWidgetlds . length; i++) { 
int wìdgetld = appWidgetlds [i] ; 

Remoteviews remoteviews = new Remoteviews (context . getPackageName () , 

R . layout . widget_list_layout ) ; 
Intent srvlntent = new Intent (context, 

CollectionAppProviderService .class ) ; 
srvlntent .putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, widgetld) ; 
srvlntent . setData (Uri .parse (srvlntent . toUri (Intent .URI_INTENT_SCHEME) ) ) ; 
remoteviews . setRemoteAdapter (R. id. stack_view, srvlntent) ; 
remoteviews . setEmptyView (R. id. stack_view, R. id . empty_view) ; 
Intent clìcklntent = new Intent (context, CollectìonAppProvider . class ) ; 
clicklntent . setAction (ACTION_LIST_SELECTED) ; 

clìcklntent .putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, wìdgetld) ; 
clicklntent . setData (Uri .parse (clicklntent . 

toUri (Intent .URI_INTENT_SCHEME) ) ) ; 
Pendinglntent clickPendinglntent = Pendinglntent . getBroadcast (context, 

CLICK_REQUEST_ID, clìcklntent, Pendinglntent . FLAG_UPDATE_CURRENT) ; 
remoteviews . setPendìnglntentTemplate (R. id. stack_view, 
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clickPendinglntent ) ; 
appWidgetManager . updateAppWidget (widgetld, remoteViews) ; 

} 

super . onUpdate (context , appWidgetManager, appWidgetlds) ; 

} 

Come sappiamo il parametro appwidgetids contiene gli identificatori delle istanze di App Widget 
che necessitano di un aggiornamento. Per questo motivo il metodo contiene un ciclo che ci consente 
di elaborare ciascuno degli App Widget di cui memorizziamo l'identificatore nella variabile di blocco 
widgetl d. L'istruzione successiva è quella che ci permette di creare la RemoteViews specificando il 
nome del package della nostra applicazione, ma soprattutto l'identificativo del layout corrispondente, 
che nelnostro caso è dato dalla costante r. layout. widget_iist_iayout. Il passo successivo è di 
fondamentale importanza, poiché ci permette di lanciare il servizio definito nel paragrafo precedente. 
Dobbiamo infatti definire un intent attraverso le seguenti istruzioni: 

Intent srvlntent = new Intent (context, CollectionAppProviderService . class) ; 
srvlntent .putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, widgetld) ; 
srvlntent . setData (Uri .parse (srvlntent . toUri (Intent .URI_INTENT_SCHEME) ) ) ; 

La prima permette la definizione di un intent esplicito, mentre la seconda ci consente di 
memorizzare, come extra, il valore dell'identificativo deWApp Widget. Un lettore attento potrebbe 
notare come queste due sole informazioni non caratterizzino l' intent in quanto gli extra non vengono 
considerati nel processo di intent resolution Per rendere l'intent univoco si utilizza il suo metodo 
tourì ( ) , il quale lo trasforma in una String che lo rappresenta. Dalla String riotteniamo poi un URI 
che impostiamo come campo DATA, che viene invece considerato in fase di intent resolution. 

NOTA 

Ricordiamo che il processo intent resolution è quello che, sulla base delle informazioni dell'intent 
lanciato, definisce a runtime il componente che lo riceverà utilizzando i suoi intent filter. 

Il passo successivo consiste nell'associazione tra la particolare istanza ài App Widget e la 
RemoteViews ritornata dalla Factory creata dal servizio associato all' intent. Questo si ha attraverso 
l'invocazione del metodo 

public void setRemoteAdapter (int viewld, Intent intent) 

Il primo parametro è il riferimento alla view che conterrà gli item, mentre il secondo è l'intent per il 
lancio del servizio descritto in precedenza. 

Quando abbiamo definito il layout ci siamo anche preoccupati di creare una Textview come quella 
che sarà visualizzata nel caso in cui non fossero disponibili delle informazioni. A tale scopo, nella 
versione 3.0 della piattaforma, alla classe RemoteViews è stato aggiunto il seguente metodo: 

public void setEmptyView (int viewld, int emptyViewId) 

Nel caso la specializzazione diviewGroup identificata dal primo parametro fosse vuota, verrà 
sostituita con la view identificata dal secondo parametro. 

Non ci resta che provvedere all'aggiornamento del widget corrente attraverso l'esecuzione della 
seguente operazione 

appWidgetManager . updateAppWidget (widgetld, remoteViews) ; 

che utilizza il riferimento all' AppWidgetManager ottenuto come parametro dell'operazione 
onupdate ( ) per modificare lo stato della RemoteViews corrente. 

Creazione di un'implementazione di Remote ViewsFactory 

Come accennato in precedenza, un RemoteViewsFactory è l'oggetto responsabile di fornire al 
nostro App Widget gli elementi da visualizzare. È quel particolare oggetto che si preoccupa di 
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mappare una view ottenuta da un normale adapter nella Remotesviews che può essere visualizzata 
neWApp Widget. Nello specifico si tratta di un'interfaccia che dobbiamo necessariamente 
implementare come fatto nella nostra classe HoroRemoteViewsFactory, che descriviamo partendo dal 
seguente costruttore: 

public HoroRemoteViewsFactory (Context context, Intent intent) { 
this .mContext = context; 

mWidgetld = intent .getlntExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, 
AppWidgetManager . INVALID_APPWIDGET_ID) ; 

} 

Il fatto di implementare un'interfaccia, e nello specifico quella descritta da 
RemoteviewsService.RemoteviewsFactory, nonpone alcunvincolo sultipo di costruttori da 
implementare. Nel nostro caso abbiamo definito un unico costruttore che prevede il riferimento al 
contesto e all'intent che contiene l'identificativo dell'istanza diApp Widget a cui Factory è associato 
dopo il lancio dell' intent. Per motivi di semplicità abbiamo salvato i due parametri in altrettante 
variabili di istanza che utilizzeremo successivamente. Si tratta del costruttore utilizzato all'interno del 

Servizio RemoteViewsService. 
NOTA 

Il lettore potrà notare come nel servizio ci sia la possibilità di creare istanze diverse dei Factory 
relativamente a diverse istanze di App Widget. È un aspetto la cui gestione è completamente di 
responsabilità dello sviluppatore. 

Come altri componenti diAndroid, anche questo Factory è sottoposto a un ciclo di vita che 
prevede l'invocazione delle seguenti due operazioni: 

public abstract void onCreateO 
public abstract void onDestroyO 

Il metodo onCreateO viene invocato dopo che è stata creata l'istanza del Factory e, ha lo scopo 
di inizializzare le informazioni che lo stesso utilizzerà, tra cui gli eventuali adapter per l'accesso a 
content provider o ad altre basi dati II metodo onDestroy ( ) viene invece invocato quando non ci 
sono più componenti che necessitano del Factory. Questo metodo dovrà quindi contenere la logica di 
liberazione delle eventuali risorse, come per esempio un cursor per l'accesso ai dati. Nel nostro 
esempio l' implementazione dei metodi precedenti è questa: 

HOverrìde 

public void onCreateO { 

mCursor = mContext . getContentResolver ( ) 

. query (UghoDB . HoroVote . CONTENT_URI , nuli, nuli, nuli, nuli) ; 
mCursorAdapter = new SimpleCursorAdapter (mContext, 

R. layout . custom_list_item, mCursor, FROMS, TOS, 0); 

} 

@Override 

public void onDestroy () { 

mCursorAdapter . swapCursor (nuli) ; 
mCursor . dose ( ) ; 

} 

Nel primo abbiamo la definizione di un cur sor Adapter che ci permetterà di accedere alle 
informazioni del content provider. Nel metodo onDestroy ( ) abbiamo la chiusura del cursore dopo 
che lo stesso è stato svincolato dal suo legame con l' adapter. 

L'operazione più importante è quella che consente di creare la Remoteviews da visualizzare 
neWApp Widget, ovvero: 

public abstract Remoteviews getViewAt ( int position) 

che assomiglia moltissimo alla corrispondente getview ( ) dell' adapter. Nel nostro caso il metodo è 
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stato implementato attraverso questo codice: 

SOverride 

public RemoteViews getViewAt ( int position) { 
final RemoteViews remoteViews = 

new RemoteViews (mContext . getPackageName ( ) , 
R . layout . custom_list_item) ; 
final Cursor itemCursor = (Cursor) mCursorAdapter . getltem (position) ; 
showData (remoteViews, itemCursor, mWidgetld) ; 
return remoteViews; 

} 

la cui logica è contenuta principalmente nel metodo showData ( ) , molto simile all'equivalente 
metodo nel paragrafo precedente: 

private void showData ( final RemoteViews remoteViews, final Cursor dataCursor, 
int widgetld) { 
final Resources res = mContext . getResources () ; 

final LocalDataModel localData = LocalDataModel . fromCursor (dataCursor ) ; 
remoteViews . setTextViewText (R. id. list_item_date, 

DATE_FORMAT. format (localData . entryDate) ) ; 
remoteViews . setTextViewText (R. id. list_item_love_vote, 

res .getString (R. string. love_value_pattern, localData. loveVote) ) ; 
remoteViews . setTextViewText (R. id. list_item_health_vote, 

res . getString (R. string . health_value_pattern, localData . healthVote) ) ; 
remoteViews . setTextViewText (R. id. list_item_work_vote, 

res . getString (R. string . work_value_pattern, localData . workVote) ) ; 
remoteViews . setTextViewText (R. id. list_item_luck_vote, 

res . getString (R . string . luck_value_pattern, localData . luckVote) ) ; 

} 

In efiètti consiste nella creazione di una RemoteViews attraverso il layout di ciascun elemento e nella 
valorizzazione delle Textview che contengono coni valori presi dal cursorAdapter creato in fase di 
inizializzazione. 

L'interfaccia prevede poi la definizione di altri metodi che si mappano molto bene su quelli di un 
normale adapter, e che sono descritti nel seguente frammento di codice: 

SOverride 

public int getCount ( ) { 

return mCursorAdapter . getCount () ; 

} 

SOverride 

public long getltemld ( int position) { 

return mCursorAdapter . getltemld (position) ; 

} 

SOverride 

public int getViewTypeCount ( ) { 
return 1; 

} 

SOverride 

public boolean hasStablelds ( ) { 
return true; 

} 

Il metodo getCount o ritornerà il numero di elementi a cui possiamo accedere attraverso 
l'omonimo metodo dell' adapter. Anche il metodo getitemid o può essere completamente delegato 
all' adapter, in quanto ha il compito di ritornare l'id dell'elemento che occupa la posizione indicata dal 
suo parametro. Il metodo getViewTypeCount o ritorna il valore 1 inquanto consideriamo un'unica 
tipologia di RemoteViews da visualizzare. Analogamente a quanto avviene negli adapter è infatti 
possibile specializzare ciascun elemento secondo criteri particolari che dipendono dai dati stessi. 
Infine, il metodo hasstabieids o deve indicare se un particolare dato mantiene lo stesso id oppure 
no nel corso della sua vita. Nel nostro caso la risposta è affermativa e quindi il valore di ritorno è 
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true. 

L'ultima operazione permette di essere avvisati di una possibile modifica delle informazioni da 
visualizzare. Nel nostro caso non gestiamo l'evento, per cui F implementazione è questa: 

public void onDataSetChanged ( ) { 
} 

Definizione dei metadati dell' App Widget 

Come fatto nel caso degli App Widget precedenti, il passo successivo consiste nella descrizione 
del componente al sistema attraverso il seguente file di configurazione: 

<appwidget-provider xmlns : android="http : // schemas . android. com/apk/ res/android" 
android:min 
android: min 

android : updatePeriodMillis=" 30000" 

android: init ialLayout="@ layout /widget_list_layout " 
android: label="CollectionAppProvider "> 
</ appwidget-provider> 

che abbiamo definito come risorsa di tipo /res/xml all'interno di un file di nome 

collection_widget_test_metadata . xml. 

Registrazione dell' AndroidManifest.xml 

Oltre alla definizione del servizio descritta in precedenza si rende necessaria la definizione 
dell' AppwidgetProvider nell'AndroidManìf est . xml. Ricordando che si tratta di una specializzazione 
di BroadcastReceìver, e che valgono le stesse regole degliApp Widget normali, la sua definizione 
sarà la seguente: 

<service android : name=" . CollectionAppProviderService" 

android : permis sìon=" android . permìssion . BIND_REMOTEVIEWS " 
android : exported=" false" /> 

<receiver android: name=" . CollectionAppProvider "> 

<meta-data android: name="android. appwidget .provider" 

android: resource=" @xml/ collection_widget_test_metadata" /> 
<intent-f ilter> 

<action android: name=" android. appwidget . action . APPWIDGET_UPDATE" /> 
</intent-f ilter> 
</receiver> 

Nel codice allegato rileviamo la presenza di un elemento <meta-data/> che fa riferimento alla 
risorsa di descrizione dei metadati. 

Test di esecuzione 

Non ci resta ora che eseguire l'applicazione attraverso gli stessi passi del progetto precedente. Il 
risultato è mostrato nella Figura 12.10. 

Il lettore noterà come neU'activity principale del progetto vi sia del codice per l'introduzione di 
valori casuali all'interno del content provider, che così è possibile visualizzare secondo la modalità a 
stack. 

Gestire la selezione degli item 

Come il lettore potrà verificare, l'utilizzo di una stackview per la visualizzazione delle RemoteViews 
ci consente di "sfogliare" le informazioni che abbiamo estratto dal nostro content provider di esempio. 
Al momento non abbiamo ancora implementato alcun meccanismo di selezione di un item che, come 
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vedremo in questo paragrafo, è abbastanza particolare. Intanto possiamo subito vedere come il 
meccanismo di selezione non possa essere basato sull'implementazione di un'interfaccia listener, in 
quanto l'oggetto responsabile della gestione deWApp Widget è un AppWidgetProvider che, ripetiamo 
nuovamente, è una specializzazione della classe BroadcastReceiver. 




Figura 12.10 Esecuzione di un App Widget associato a una Collection. 

E un componente che viene attivato per il tempo necessario alla gestione di un intent di 
aggiornamento, il quale deve essere il più breve possibile per non incorrere in un errore diANR. 
Dovrà quindi essere un meccanismo basato sul lancio di un intent, che dovrà contenere informazioni 
relative alla particolare istanza del widget e soprattutto identificare un solo elemento tra quelli 
visualizzati. Come vedremo nel nostro esempio, si tratta di un intent costruito in due passi distinti II 
primo ci permetterà di creare quello che la documentazione chiama template intent e che contiene 
tutte le informazioni che dipendono dal particolare widget ma non dalla Remoteviews in esso 
selezionata. Il secondo dovrà invece specializzare (fili, riempire) l' intent di template con le 
informazioni dello specifico elemento selezionato e poi della RemoteViews selezionata. La prima 
definizione dovrà essere fatta nel nostro AppWidgetProvider, mentre la seconda in corrispondenza 
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della creazione della Remoteviews nel Factory. Per comprendere questo meccanismo all'apparenza 
contorto abbiamo esteso l'esempio aggiungendo il codice digestione dell'evento di selezione (di clic) 
precedentemente commentato. 

Come più volte sottolineato un BroadcastReceiver è un componente in grado di attivarsi a seguito 
della ricezione di un intent di broadcast, ovvero di una "segnalazione" da parte di un componente 
verso l'intero sistema. Si tratta del meccanismo che la piattaforma utilizza per segnalare eventi come 
rinserimento di una SD Card, la sua rimozione, la percentuale di batteria, una variazione della 
luminosità del display e altri ancora. È un componente che viene attivato in particolari momenti e che 
svolge delle operazioni che devono essere il più brevi possibile anche perché, nel caso di più 
BroadcastReceiver attivati a seguito di un intent di broadcast, i metodi onReceive ( ) corrispondenti 
vengono eseguiti uno dopo l'altro. Le specializzazioni della classe AppwidgetProvider implementano il 
metodo onReceive ( ) HI modo da gestire il ciclo di vita dei diversi App Widget invocando i relativi 
metodi di callback, tra cui il metodo onupdate ( ) visto in precedenza. Dopo questa premessa capiamo 
che il primo passo da seguire per la gestione, all'interno di un AppwidgetProvider, di un intent diverso 
da quello di update del widget consiste nella definizione di una nostra action e mWoverride del 
metodo onReceive ( ) per poterlo poi riconoscere. Questo è il motivo della presenza di questa 
dichiarazione nella nostra classe coiiectionAppProvider: 

public final static String ACTION_LIST_SELECTED = 

"android. appwidget . AppWidgetManager . action . ACTION_LIST_SELECTED " ; 

Come accennato in precedenza, l'intent che dovrà essere lanciato dopo la selezione di un elemento 
dcWApp Widget viene creato in due step, che riguardano rispettivamente il particolare widget e quindi 
il particolare elemento al suo interno. La prima parte generica si definisce all'interno del metodo 
onupdate o delnostro AppwidgetProvider attraverso le seguenti righe di codice: 

Intent clicklntent = new Intent (context , CollectionAppProvider . class) ; 
clicklntent . setAction (ACTION_LIST_SELECTED) ; 

clicklntent . putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, widgetld) ; 
clicklntent . setData (Uri .parse (clicklntent . toUri ( Intent . URI_INTENT_SCHEME) ) ) ; 
Pendinglntent clickPendinglntent = Pendinglntent . getBroadcast (context , 
CLICK_REQUEST_ID, clicklntent, Pendinglntent . FLAG_UPDATE_CURRENT) ; 
remoteviews . setPendinglntentTemplate (R . id. stack_view, clickPendinglntent ) ; 

La prima di queste istruzioni permette la creazione di un intent che è di tipo esplicito e relativo allo 
stesso componente descritto dalla classe CollectionAppProvider: 

Intent clicklntent = new Intent (context , CollectionAppProvider . class) ; 

Si tratta di un intent che dovrà essere gestito dalla stessa classe ma che necessita di un qualche 
accorgimento per poterlo distinguere da quelli di update. Questo è il motivo della presenza della 
seguente istruzione, che assegna all' intent la nostra action definita in precedenza. 

clicklntent . setAction (ACTION_LIST_SELECTED) ; 

L'istruzione successiva è molto semplice e consente di inserire nel' intent l'informazione relativa ala 
particolare istanza di widget a cui lo stesso fa riferimento: 

clicklntent .putExtra (AppWidgetManager . EXTRA_APPWIDGET_ID, widgetld) ; 

Anche qui abbiamo l'esigenza di rendere l'intent unico in quanto le sole informazioni inserite 
attraverso degl extra vengono ignorate. Questo è 1 motivo per utilizzare l'istruzione descritta in 
precedenza: 

clicklntent . setData (Uri .parse (clicklntent . toUri ( Intent . URI_INTENT_SCHEME) ) ) ; 

Il passo successivo consiste nella creazione delpendìngintent da associare al' evento di selezione 
attraverso l'istruzione 
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Pendinglntent clickPendinglntent = Pendinglntent . getBroadcast (context , 

CLICK_REQUEST_ID, clicklntent, Pendinglntent . FLAG_UPDATE_CURRENT) ; 

Innanzitutto si richiede la creazione di un Pendinglntent, in quanto si tratta di un modo per 
permettere l'elaborazione di un intent a un processo diverso da quello che lo ha creato, cosa tipica 
deiBroadcastReceiver. Il secondo aspetto fondamentale è legato all'utilizzo delflag 
flag_update_current visibile nel codice precedente. Le API a diposizione non permettono infatti che 
venga creato un Pendinglntent diverso per ciascuna delle kemoteviews che possono essere 
selezionate. Per questo motivo si è scelto di creare qui un unico Pendinglntent di riferimento 
(template) associato all'intero App Widget, e successivamente consentire la modifica degli extra a 
seguito delle varie selezioni L'istruzione precedente permette infatti di verificare se un Pendinglntent 
con le stesse caratteristiche esista o meno. Nel caso in cui esistesse già, lo stesso verrebbe riutilizzato 
semplicemente aggiungendovi gli extra dell' intent passato come parametro. In sintesi il nostro App 
Widget utilizzerà sempre lo stesso Pendinglntent in cui modificherà, a ogni evento, solamente i valori 
degli extra che identificheranno l'elemento selezionato e che verranno invece impostati dalle 
Remoteviews corrispondenti, come vedremo successivamente. Attraverso l'istruzione 

remoteViews . set Pendinglntent Template (R . id. stack_view, clickPendinglntent ) ; 

abbiamo infatti informato la Remoteviews che il template di Pendinglntent lanciato a seguito della 
sua selezione è quello passato come secondo parametro, ovvero quello creato precedentemente. 

L'informazione relativa al valore dell'extra che identificherà la particolare Remoteviews selezionata 
sarà impostato quando si definisce la Remoteviews stessa e quindi nel metodo getviewAt o - o 
meglio, nel metodo showDatao da esso invocato - del Factory descritto dalla classe 
HoroRemoteviewsFactory che avevamo, anche in quel caso, inserito nel codice sorgente ma 
momentaneamente commentato. Le istruzioni aggiunte sono le seguenti: 

Intent clickFillIntent = new Intent (); 

ci ickFi 11 Intent .putExtra (UghoDB . HoroVote . ENTRY_DATE , localData . entryDate) ; 
remoteviews . setOnClickFillInlntent (R . id . list_item_date, clickFillIntent ) ; 

In realtà è un meccanismo per definire un intent con le informazioni extra da "fondere" con quelle 
del? endinglntent di template. Nel nostro caso inseriamo le informazioni relative alla data dell'entry. 
L'istruzione che consente di integrare l' intent nel framework è questa 

remoteviews . setOnClickFillInlntent (R . id. teamRowLayout , clickFillIntent ) ; 

dove il primo parametro identifica la view cliccabile della Remoteviews, ovvero dell' item di 
riferimento. 

L'ultimo passo consiste nella gestione dell' intent di selezione da parte del particolare 
AppWidget Provider che, in base a quanto descritto sopra, consisterà neH'override del metodo 
onReceive ( ) nel seguente modo: 

public void onReceive (Context context, Intent intent) { 

if (ACTION_LIST_SELECTED .equals (intent .getAction () ) ) { 

long dateSelected = intent . getLongExtra (UghoDB . HoroVote . ENTRY_DATE, OL) ; 
String message = nuli; 
if (dateSelected > OL) { 

message = "Selected date:" + DATE_FORMAT . format (dateSelected) ; 
} else { 

message = "Problem selecting date!"; 

} 

Toast toast = Toast .makeText (context, message, Toast . LENGTH_SHORT) ; 
toast . show ( ) ; 
} else { 

super . onReceive (context, intent) ; 

} 

} 
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Notiamo come l'action venga utilizzata proprio per poter distinguere l'intent relativo alla selezione 
degli elementi da quello di update dcWApp Widget. Eseguendo l'applicazione il lettore potrò 
verificare come la selezione di un elemento porti alla visualizzazione di un Toast con il messaggio 
relativo alla data selezionata. 

Utilizzo dei widget sulla LockScreen 

Dalla versione 4.2 della piattaforma è possibile candidare i widget a quella che si chiama 
LockScreen, ovvero quella particolare Home che viene visualizzata quando il dispositivo è bloccato. 
Anche stavolta si tratta di un parametro di configurazione che possiamo impostare attraverso 
l'attributo android:widgetcategory, il quale può assumere uno o entrambi i seguenti valori: 

• home_screen 

• keyguard 

Il primo è il valore di default che ogni widget possiede e che descrive quei widget che possono 
appartenere alla Home. Nel caso in cui volessimo aggiungere il nostro widget alla lock screen 
possiamo aggiungere anche il valore keyguard. Supponiamo di modificare il nostro file di 
configurazione di nome collection_widget_test_metadata . xml nell'applicazione precedente (deve 
infatti avere un API Level almeno 17) come segue: 

<appwidget -provider xmlns : android="http : / / schema s . android. com/apk/ res/android" 
android:min android:min 
android : updatePeriodMillis=" 30000" 

android: initialLayout="@ layout /widget_list_layout " 
android: widgetCategory=" keyguard | home_screen" 

android: label="CollectionAppProvider "> 
</ appwidget-provider> 

A questo punto il nostro widget può essere aggiunto alla lock screen Ogni dispositivo può avere il 
proprio meccanismo di aggiunta di un widget alla lock screen. Nel caso delNexus 4 si può eseguire 
lo swipe visualizzando lo schermo alla sinistra di quello che contiene di default l'orologio, come nella 
Figura 12.11. Selezionando il pulsante + è possibile andare a una schermata con l'elenco dei widget 
che contiene questa opzione, come nella Figura 12.12. Una volta selezionato vedremo il nostro 
widget nella schermata di lock, come nella Figura 12.13. 

Le API ci danno anche la possibilità di capire a runtime se il widget è stato aggiunto alla Home o 
alla lock screen in modo da personalizzarne il layout. È un controllo che solitamente viene eseguito nel 
metodo onupdate o del provider, dove si possono eseguire queste istruzioni: 

Bundle optìons = appWidgetManager . getAppWidgetOptions (wìdgetld) ; 
ìnt category = options . getlnt (AppWidgetManager 

.OPTION_APPWIDGET_HOST_CATEGORY, -1) ; 
boolean isLockScreen = category == 

AppWidgetProvider Inf o . WIDGET_CATEGORY_KEYGUARD ; 
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Figura 12.12 Selezioniamo il nostro widget tra quelli disponibili. 





Figura 12.13 II widget nella schermata di lock. 



Attraverso il WidgetManager accediamo a un Bundie che contiene le opzioni di un widget di id 
conosciuto. Associato alla chiave AppwidgetManager .option_appwidget_host_category vi è poi un 
valore intero che ne descrive la categoria, che possiamo poi confrontare con il valore rappresentato 
dalla costante AppwidgetProviderinf o . widget_category_keyguard. Sempre dalla versione 4.2 è 
possibile utilizzare l'attributo android: initiaiKeyguardLayout per specificare un layout per la 
schermata di lock. Si tratta di un layout che viene visualizzato non appena il widget viene aggiunto per 
essere poi sostituto da quello reale al primo update. 

Conclusioni 

In questo capitolo abbiamo descritto ima delle funzionalità più interessanti fornite dalla piattaforma 
Android, ovvero la possibilità di arricchire la Home del dispositivo con informazioni dinamiche. 
Abbiamo visto inizialmente un esempio relativo alla creazione di widget semplici per poi creare un 
widget per mostrare un elenco di informazioni. Abbiamo quindi concluso trattando una feature 
introdotta in Android 4.2 che prevede la possibilità di visualizzare dei widget nella schermata di lock, 
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ovvero quella che compare quando il dispositivo è bloccato. 



Capitolo 13 



Sistemi di autenticazione 



Una delle parti più importanti di un' applicazione mobile è quella che va sotto il nome di modulo di 
autenticazione. Specialmente per quelle applicazioni che si integrano con i social network più làmosi 
come Facebook, Twitter e Google+, si sente la necessità di un meccanismo che permetta di 
riconoscere gli utenti in base a diverse tipologie di credenziali che, nella forma più semplice, sono 
caratterizzate dalla classica accoppiata username-password. In altri casi si può fare affidamento sui 
sistemi di autenticazione dei social network condividendo con essi solamente un'informazione 
chiamata token. Android ha percepito da subito l'importanza del problema mettendo a disposizione 
un piccolo framework che ha nefl'AccountManager il suo componente principale e che permette di 
accentrare in un unico luogo la gestione dell'autenticazione e dell'autorizzazione liberando le singole 
applicazioni dalla realizzazione di un codice che si sarebbe rivelato ripetitivo. 

In questo capitolo vedremo come funziona questo framework realizzando con esso l'intero sistema 
di autenticazione della nostra applicazione UGHO. Vedremo poi come integrare questo meccanismo 
con quelli di Facebook attraverso l'utilizzo di opportune librerie fornite dallo stesso social network. 
Concluderemo quindi il capitolo con la realizzazione di un sistema di sincronizzazione che utilizza la 
classe syncAdapter fornita dalla piattaforma Android. 

Un tipico scenario di utilizzo 

Supponiamo di disporre di un'applicazione che permetta la gestione di una serie di utenti, ciascuno 
dei quali è dotato delle proprie credenziali per l'accesso a un particolare insieme di servizi Per 
accedere alle funzionalità del sistema, l'utente deve autenticarsi sottoponendo delle credenziali 
tipicamente sotto forma di imo username e di una passtvord. Supponiamo ora di voler realizzare 
un'applicazione per Android che acceda agli stessi servizi. In generale l'applicazione dovrà in qualche 
modo richiedere le credenziali all'utente per l'autenticazione ogni volta che la stessa viene avviata per 
eseguire il login sul sistema e quindi permetterne l'accesso. Successivamente si presenta l'occasione 
di realizzare una nuova applicazione Android, la quale accede agli stessi servizi, eventualmente 
elaborando le stesse informazioni in modo diverso. Anche questa applicazione dovrà implementare gli 
stessi meccanismi di autenticazione della precedente. Proprio per la natura dinamica delle applicazioni 
Android, si è resa necessaria la realizzazione di un piccolo framework che consentisse di 
disaccoppiare le operazioni legate alla gestione di un account da quelle specifiche di ogni 
applicazione. L'obiettivo era quello di creare un sistema che permettesse alle singole applicazioni di 
sapere se l'utente è autenticato rispetto a un particolare sistema senza dover per forza gestire 
l'inserimento e l'invio delle credenziali al server di autenticazione. 

Molti di questi sistemi adottano delle tecniche in grado di aumentare la propria sicurezza e che 
consistono nell'utilizzo di un token, un'informazione che viene generata al momento dell'autenticazione 
e che viene utilizzata successivamente al posto delle credenziali. In questo modo l'applicazione può 
richiedere un token al sistema di autenticazione che poi userà per tutte le interazioni con il servizio 
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stesso. L'efficacia nell' utilizzo di questo token sta principalmente nel tatto che cambia spesso e può 
essere usato da applicazioni che non conoscono le credenziali dell'utente. Un procedimento di questo 
tipo è quello utilizzato, per esempio, da Facebook. Un aspetto importante del framework di account 
di Android è che il come e il quando questo token viene impiegato dipendono dalla particolare 
applicazione e dalla logica di autenticazione lato server. Vedremo come esso permetta solamente la 
creazione e l'invalidazione del token e la gestione dell'interazione con l'utente per l'acquisizione delle 
credenziali e la verifica delle stesse. La presenza di un token può essere utile anche nel caso in cui vi 
sia la necessità di discriminare l'accesso a servizi diversi forniti dallo stesso server. Pensiamo, anche in 
questo caso, a un account Gmail e alla richiesta di token differenti per l'accesso alla funzionalità di 
mail, di document management, di calendar e altro ancora. 

Per descrivere il funzionamento di questo meccanismo di autenticazione riutilizzeremo gli stessi 
servizi dummy che abbiamo utilizzato nell'attuale implementazione aggiungendo solamente il valore 
del token che abbiamo al momento impostato come statico. 

Il lettore potrà implementare il servizio lato server a proprio piacimento. Nel nostro caso abbiamo 
messo a disposizione il servizio con token all'indirizzo 

http : / /www . mas s imocarl i . eu/ android/ logìn_t .php Gradle. 

Per la creazione di un account dovremo inviare una richiesta in GET al precedente indirizzo 
specificando le informazioni relative a uno username "pippo" e a una password relativa all'MD5 di 
"android" che è 

C31b32 364cel9ca8fcdl50a417ecce58 

In sintesi, per eseguire un'autenticazione con successo bisognerà invocare il seguente indirizzo, 
dove abbiamo eliminato la prima parte per motivi di spazio: 

/ login_t . php?username=pippo&password=c31b32364cel 9ca8f cdl50a417ecce58 

Il risultato sarà il seguente JSON: 

{ 

result: "OK", 
username: "pippo", 
email: "pippo@pippo.com", 
birthDate: 672346738678, 
location: "London", 
token: "my_token" 

} 

Rispetto a quanto visto nella prima implementazione, abbiamo introdotto il campo token che 
conterrà appunto il valore del token che poi potrà essere usato come credenziale di accesso ai vari 
servizi. In questa fase è di fondamentale importanza sottolineare come la creazione di un account con 
l'AccountManager non corrisponda all'operazione di registrazione: l'account deve già esistere lato 
server. Quando l'account viene creato sul client non si fa altro che generare questo meccanismo 
automatico di gestione delle credenziali 

In caso di credenziali errate il risultato sarà ancora un JSON, ma questa volta del tipo 

{ 

result: "KO", 

message: "wrong credentials" 

} 

Il secondo servizio che considereremo è quello relativo alla verifica di validità del token. In realtà 
nei sistemi reali il token viene passato ogni volta che si ha la necessità di interagire con il server, per 
cui la realizzazione di un servizio di sola verifica potrebbe risultare superfluo. Nel nostro esempio non 
abbiamo implementato la verifica del token durante la sincronizzazione per cui quello scelto è un buon 
compromesso. 
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Anche in questo caso si tratta di un servizio da invocare in GET che noi abbiamo implementato in 
corrispondenza dell'indirizzo 

http : / /www .massimocarli . eu/ andrò id/ check_token . php 

che possiamo quindi invocare nel seguente modo passando il valore del token come parametro 

http : / /www .massimocarli . eu/ andrò id/ check_token . php?token=my_token 

I JSON di risposta sarà molto semplice, e precisamente 

{ 

result: "OK" 

} 

in caso di successo e 

{ 

result: "KO" 

} 

in caso di tàllimento. Ripetiamo ancora una volta che questi sono servizi fittizi che ci permettono di 
descrivere il meccanismo lato client in modo semplice; nei sistemi reali si tratta di servizi perlopiù 
REST che permettono di interagire con sistemi di autenticazione più sofisticati. La natura dei servizi 
esposti è comunque la stessa. 

Il componente AccountManager 

Nel paragrafo precedente abbiamo realizzato e descritto un semplice sistema di autenticazione che 
permette la gestione sia delle normali credenziali diusername e password sia la possibilità di utilizzare 
un token Un'applicazione Android che intende accedere ai servizi protetti da un sistema di 
autenticazione come il nostro dovrà quindi eseguire alcune semplici operazioni: 

• verifica della presenza di un account; 

• creazione di un account per il sistema di autenticazione; 

• richiesta di conferma dell'account; 

• evetuale richiesta di un token per il servizio; 

• invalidazione esplicita del token. 

Sono servizi che Android mette a disposizione attraverso il componente AccountManager che, 
come detto, è descritto dall'omonima classe del package android. accounts. 
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Figura 13.1 Gestione standard degli account in Android. 

Nel corso del capitolo ci occuperemo della riscrittura dell'attuale meccanismo di autenticazione ma 
questa volta secondo le regole standard della piattaforma Android. 

Prima di entrare nel dettaglio delle funzionalità e dell'implementazione, descriviamo un tipico caso 
d'uso di questo componente. Come detto un'applicazione Android potrà avere la necessità di 
accedere a servizi remoti protetti per i quali occorre acquisire delle credenziali associate a un account. 
È bene precisare nuovamente come la creazione dell'account sul particolare server non è gestita dal 
framework di autenticazione, per cui l'applicazione lo dovrà eventualmente implementare in modo 
personalizzato oppure la registrazione al servizio dovrà avvenire attraverso modalità diverse come per 
esempio quella web. L'app Reazione dovrà, come prima cosa, verificare se esiste già un account per il 
particolare servizio. Per farlo dovrà, come prima cosa, ottenere il riferimento all' AccountManager 
attraverso il suo metodo statico di Factory a cui serve un parametro rappresentato dal classico 

Oggetto Context: 

public static AccountManager get (Context context) 

È importante precisare come, a differenza di altre che vedremo successivamente, questa non è 
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un'operazione che richiede un permesso. Per completezza diciamo che, anche nel caso 
dell' AccountManager, Android implementa il pattern Observer attraverso la definizione dell' interfaccia 
onAccountsupdateListener, la quale permette di ricevere notifiche relative a eventuali modifiche 
nell'elenco degli account registrati. Si tratta di un'opzione molto utile; pensiamo per esempio a un 
servizio di sincronizzazione che accede alla nostra mail a intervalli regolari utilizzando un particolare 
account che viene poi cancellato dall'utente attraverso l'interfaccia di configurazione. 

Una volta ottenuto il riferimento all' AccountManager, l'applicazione dovrà verificare se esiste già un 
account per l'accesso ai servizi di interesse. Per farlo, la classe AccountManager, ci mette a 
disposizione diverse operazioni, la più semplice delle quali è la seguente: 

public Account!] getAccounts ( ) 

Questa volta si tratta di un'operazione che, per poter essere eseguita, necessita del permesso 
associato al valore android. permission.GET_AccouNTS nel' AndroidManif est .xml. Come possiamo 
vedere dalla firma, 1 risultato è rappresentato da un array di oggetti di tipo Account descritti 
dal'omonima classe del package android . account s. È una classe più semplce di quelo che si pensi; 
consente di incapsulare, attraverso dele proprietà pubblche, le informazioni relative al nome e al tipo 
del' account. Il nome è, per esempio, lo username del' account, mentre Itipo è quella informazione 
che permette di distinguere un account Gmal da quel! di Facebook o di Twitter. È importante notare 
come si tratti di una classe che implementa Parceiabie, per cui potrà essere utilizzata come valore da 
inserire al' intemo degl extra di un intent, come faremo più volte quando creeremo 1 sistema di 
autenticazione per 1 nostro server. 

Di solito un'applcazione non richiederà comunque tutti i possibil account nel dispositivo ma sarà 
interessata solo a queli di un particolare tipo. Questo è 1 motivo della presenza, nella classe 

AccountManager, delmetodo 

public Account!] getAccountsByType (String type) 

che, come 1 precedente, richiede 1 permesso di tipo get_accounts. Il valore per Itipo 
del' account è qualcosa che dipende dal particolare sistema di autenticazione. Nel' emulatore questo 
non succede, ma nella maggior parte dei dispositivi real esiste la possibiltà di definire gl account 
relativi a Facebook, Twitter o ad altri sistemi di autenticazione. Se provassimo a elencare gl account 
registrati su un Nexus 4 otterremmo i tipi riportati di seguito, i qual dipendono dal' implementazione 
di quelo che si chiama Authenticator e che successivamente realizzeremo per 1 nostro sistema. 

Per elencare tutti i tipi degl account presenti utilizziamo le seguenti righe di codice (con 1 permesso 

android. permìs Sion . GET_ACCOUNTS nel' AndroidManif est . xml): 

AccountManager am = AccountManager . get (this ) ; 
Account!] accounts = am . getAccounts () ; 
for (Account account: accounts) { 

Log. i ("ACCOUNT", "type:" + account .type) ; 

} 

Otteniamo 1 seguente elenco: 

com. google 
com. github 

com. facebook . auth . login 

com. twitter .android . auth .login 

1 quale dipende dal' insieme dele applcazioni installate con i relativi utenti creati attraverso un 
meccanismo sferrile a quelo che vedremo e implementeremo. Il lettore potrebbe averne quindi di più 
come di meno fino a nessuna. 

Una volta richiesto l'elenco degl account di un particolare tipo, si potrebbero verificare 
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sostanzialmente le seguenti tre situazioni; 

• non esiste alcun account; 

• esiste un unico account; 

• esiste più di un account. 

Se non esiste alcun account l'applicazione dovrebbe richiedere all'utente di crearne imo per poter 
accedere ai vari servizi In questo caso l'applicazione non farà altro che invocare il seguente metodo 
della classe AccountManager che, vista la sua complessità, merita una serie di considerazioni (che, 
fortunatamente, saranno utili anche in altri metodi). Diciamo irmnzitutto che si tratta di un metodo per 
il quale è necessario acquisire il permesso associato al valore android.permission.MANAGE_AccouNTs: 

public AccountManagerFuture<Bundle> addAocount (String accountType, 
String authTokenType, Stringi] requiredFeatures, 
Bundle addAccountOptions, Activity activity, 
AccountManagerCallback<Bundle> callback, Handler handler) 

Nella precedente firma del metodo addAccount ( ) abbiamo evidenziato il tipo di ritomo e i vari 
parametri Innanzitutto vediamo come il valore di ritomo sia rappresentato da un oggetto di tipo 
AccountManagerFuture<Bundie>. È una specializzazione dell'interfaccia Future, l'astrazione di un 
oggetto sul quale è possibile attendere che si completi un particolare task al fine di ottenerne un 
risultato. Nel Capitolo 8 abbiamo già visto che cos'è un thread e in che cosa si distingue dal task. In 
sintesi un thread può eseguire il proprio metodo all'infinito senza mai terminare. Un task, per quanto 
lungo, dovrà prima o poi terminare il proprio compito ed eventualmente produrre un risultato. Al fine 
di ottimizzare le performance, capita spesso che itask vengano inseriti all'interno di una cosa per cui 
non si conosce esattamente non solo l'istante di fine ma neanche quello di inizio. Il metodo di 
inserimento del task nella cosa dovrà però ritornare un riferimento a un qualche oggetto che è astratto 
dall'interfaccia Future. Un oggetto che implementa l'interfaccia Future<T> è un oggetto che dispone 
dell'implementazione del metodo get ( ) , che ritornerà appunto un riferimento all'oggetto di tipo t 
risultato dell'elaborazione del task corrispondente. Per quanto detto prima, il metodo get o 
dell'oggetto Future<T> non potrà ritornare subito, per cui si tratta di un metodo bloccante la cui 
invocazione dovrà avvenire, preferibilmente ma non per forza, in un thread separato rispetto a quello 
dell' accodamento. Contestualizzando al nostro caso, un oggetto di tipo 

AccountManagerFuture<Bundie> è sostanzialmente un oggetto che ritornerà un Bundie contenente le 
informazioni relative a un'operazione di gestione degli account che può essere eseguita in modo 
asincrono. Qui il particolare task consiste nella creazione di un account di tipo specificato dal 

parametro di nome accountType. Il tipo generico di AccountManagerFeature è un Bundle che il 

sistema di autenticazione utilizza per lo scambio di messaggi con le varie applicazioni che, 
ricordiamolo, non sono eseguite necessariamente nello stesso processo (anzi il più delle volte sono 
eseguite in processi diversi). L'oggetto AccountManagerFuture<Bundle> è subito ritornato dal metodo 
addAccount ( ) ma si tratta di qualcosa su cui sarà possibile attendere l'esito dell'operazione attraverso 
un thread che dovrà preferibilmente essere diverso da quello principale per non incorrere inunANR 
(Application Not Responding). 

Se osserviamo la documentazione della classe AccountManagerFuture vediamo come disponga dei 
classici metodi di un Future, i quali permettono di verificare se il task associato è andato a buon fine, 
se ha dato errori o se è stato interrotto. In questo caso specifico, sarà molto importante il suo metodo 
getResuit o , che ritornerà un Bundle che conterrà tutte le informazioni relative all'operazione 
sull'account, ovvero, nel caso della creazione, il nome e il tipo. In caso di errore ilBundie conterrà 
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l'informazione corrispondente attraverso l'opportuna chiave. 

Il parametro authTokenType consente di specificare l'eventuale tipo di token di cui si richiede la 
creazione per questo particolare tipo di account. Un sistema di autenticazione potrebbe infatti gestire 
diversi token a seconda del servizio. Il sistema di creazione di un account, che come vedremo 
interagisce con il lato server del sistema, potrebbe avere bisogno di altre informazioni che possiamo 
impostare attraverso i parametri tequiredFeatures e addAccountoptions. Il primo èunarraydi 
string che contiene dei valori specifici del servizio che permettono di configurare lo stesso in base 
alle diverse opzioni Un servizio di mappe, per esempio, potrebbe essere configurato specificando il 
grado di accuratezza dei valori che si intendono ricevere. Un altro esempio riguarda la possibilità di 
creare un account non solo per Gmail ma anche per Google Drive o Calendar. Il secondo parametro 
contiene invece delle informazioni in un Bundie che saranno quelle che il componente di interazione 
con il server di autenticazione può utilizzare per comunicare con esso. 

Come vedremo quando realizzeremo un sistema di autenticazione per il nostro server, la creazione 
di un account presuppone la richiesta all'utente di alcune informazioni tra cui, nella maggior parte dei 
casi, uno username e una password. Per farlo, il particolare Authenticator (l'oggetto che vedremo 
essere responsabile di questa interazione) non farà altro che lanciare una particolare activity attraverso 
il metodo startActivity o . Per questo motivo esiste il parametro activity il cui riferimento serve 
solamente per il lancio dell'attività di configurazione. Tale parametro potrà essere nuli, nel qual caso 
ilBundie che si otterrà dall'oggetto AccountManagerFuture<Bundie> conterrà l'intent che, a questo 
punto, dovrà essere eventualmente lanciato in modo esplicito per la visualizzazione dell' activity di 
richiesta all'utente. 

Gli ultimi due parametri del metodo addAccount ( ) sono quelli che permettono di gestire l'oggetto 
AccountManagerFuture<Bundie> di ritorno nella modalità asincrona. L'interfaccia 
AccountManagerCaiiback<Bundie> contiene infattila definizione del solo metodo 

public abstract void run (AccountManagerFuture<V> future) 

il quale permette la notifica dello stesso AccountManagerFuture<v> ottenuto come tipo di ritorno. 
L'ultimo parametro è semplicemente l'eventuale handler all'interno del quale verrà eseguita la notifica 
precedente. Nel caso in cui questo parametro fosse nuli, il significato è quello di eseguire la notifica 
nel thread principale. 

Questo il caso in cui l'applicazione non trovasse alcun account del tipo richiesto. Nel caso in cui ve 
ne fosse uno solo, l'applicazione dovrà verificare se l'account ha i requisiti necessari. Abbiamo infatti 
parlato difeature. È sufficiente utilizzare questo metodo della classe AccountManager: 

public AccountManagerFuture<Boolean> hasFeatures (Account account, 
Stringi] features, AccountManagerCallback<Boolean> callback, 
Handler handler) 

il cui significato dei vari parametri dovrebbe a questo punto essere noto in quanto analogo a quello 
del metodo addAccount o visto in precedenza. L'unica differenza consiste nel tipo di oggetto ritornato 
dall' AccountManagerFeature, che ora è unBooiean che indica appunto se l'account passato dispone 
o meno delle funzionalità richieste. In alternativa all'invocazione del metodo getAccountBy Type ( ) e 
quindi hasFeature < ) è possibile invocare direttamente il seguente: 

public AccountManagerFuture<Account [ ] > getAccountsByTypeAndFeatures ( 

String type, Stringi] features, AccountManagerCallback<Account [ ] > callback, 
Handler handler) 

In questo caso le feature richieste si intendono come obbligatorie, mentre l'utilizzo della coppia di 
metodi precedenti può essere utile nel caso in cui la loro presenza fosse opzionale per l'attivazione o 
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meno di alcune funzionalità dell'applicazione. 

Nel caso in cui vi fossero più account che soddisfano le richieste dell'applicazione sarà buona 
norma richiedere all'utente quali di queste usare e poi fornire un'opzione per passare da una all'altra. 
Nel caso in cui esistesse già un account, l'applicazione potrebbe richiedere all'utente la verifica delle 
credenziali attraverso l'invocazione del metodo 

public AccountManagerFuture<Bundle> conf irmCredentials (Account account, 

Bundle options, Activity activity, AccountManagerCallback<Bundle> callback, 
Handler handler) 

di firma simile a quello di creazione dell'account. Sarà responsabilità del modulo di autenticazione 
la presentazione di un' activity per la richiesta delle credenziali e quindi per la loro verifica. In alcuni 
casi, il modulo di autenticazione non richiederà l'inserimento esplicito diusername e password (o in 
genere delle credenziali) da parte dell'utente, ma eseguità una verifica attraverso un accesso al server 
con le credenziali già memorizzate, richiedendo all'utente le informazioni solo nel caso di verifica non 
andata a buon fine. Nel caso in cui s'intendesse richiedere in modo esplicito le credenziali all'utente 
per una nuova autenticazione, il metodo da invocare sarebbe questo: 

public AccountManagerFuture<Bundle> updateCredentials (Account account, 
String authTokenType, Bundle options, Activity activity, 
AccountManagerCallback<Bundle> callback, Handler handler) 

In precedenza abbiamo parlato di token, per cui l'applicazione potrebbe richiedere al sistema di 
autenticazione questa informazione per poi utilizzarla in un modo che, ricordiamo, dipenderà dal 
particolare servizio. Il sistema di autenticazione di Andro id non entra nel merito di come e quando 
questo token viene usato ma ne permette solamente la creazione e la verifica. 

Relativamente alla gestione degli account facciamo notare la presenza del metodo 

public boolean addAccountExplicitly (Account account, String password, Bundle userdata) 

il quale consente rinseriemento esplicito di un account all'interno di quelli gestiti 
dall' AccountManager. Si tratta diunmetodo che, come vedremo, verrà utilizzato dai vari moduli di 
autenticazione per l'inserimento degli account verificati dopo un accesso al server. 

La gestione del token 

Per quei sistemi che lo prevedono, l'applicazione potrà richiedere il token attraverso l'invocazione 
di uno dei metodi che la classe AccountManager mette a disposizione al riguardo. Il più importante di 
questi è il seguente: 

public AccountManagerFuture<Bundle> getAuthToken (Account account, 
String authTokenType, Bundle options, Activity activity, 
AccountManagerCallback<Bundle> callback, Handler handler) 

Osserviamo come tra i parametri vi siano le informazioni relative al tipo di token e alle eventuali 
opzioni È un metodo che solitamente viene invocato quando l'applicazione è in primo piano, e quindi 
può eventualmente richiedere le credenziali in modo esplicito all'utente prima della creazione 
dell'eventuale nuovo token. In corrispondenza dell'invocazione del precedente metodo, il sistema di 
autenticazione verifica, infatti, l'esistenza del token nella cache. Nel caso non esistesse si 
richiederebbe la generazione di un nuovo token, che avverrà in modo automatico qualora fosse 
disponibile la password, mentre richiederà un suo nuovo inserimento da parte dell'utente in caso 
contrario. 
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Figura 13.2 Diagramma delle attività per la creazione di un token. 

Nel caso in cui il componente richiedente il token non fosse visibile, come può succedere nel caso 
di Service, la modalità di interazione con l'utente è quella della notifica nella barra superiore. In questi 
casi, il metodo da utilizzare per la richiesta del token sarà il seguente: 

public AccountManagerFuture<Bundle> getAuthToken (Account account, 
String authTokenType, boolean notifyAuthFailure, 

AccountManagerCallback<Bundle> callback, Handler handler) 

Abbiamo evidenziato il parametro notifyAuthFailure che, se a true, indica al sistema di 
autenticazione di generare una notifica per indiare l'utente all'inserimento esplicito delle credenziali. Il 
processo di gestione di questo metodo è analogo al precedente nella prima parte ma si differenza 
nella modalità di notifica. Il valore di ritomo del metodo conterrà infatti un intent che l'applicazione 
dovrà lanciare per la visualizzazione dell'attività di richiesta esplicita delle credenziali. Se il parametro 
notifyAuthFailure è a true, lo stesso intent verrà lanciato al momento di selezione della notifica da 
parte dell'utente. Nel caso della notifica è possibile che l'utente non inserisca le credenziali richieste 
per lungo tempo. Per questo motivo, il sistema prevede il lancio di un intent in broadcast associato 
all'azione login_accounts_changed_action che i vari componenti dovranno ricevere per ritentare 
l'accesso al server e quindi ottenere il token desiderato. 
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Figura 13.3 Gestione del token attraverso una notifica. 

L'ultimo metodo per la creazione di un token consente di specificare le feature analogamente a 
quanto latto per la creazione dell' account: 

public AccountManagerFuture<Bundle> getAuthTokenByFeatures (Strìng accountType, 
String authTokenType, Stringi] features, Activìty activity, 
Bundle addAccountOptions, Bundle getAuthTokenOptions, 
AccountManagerCallback<Bundle> callback, Handler handler) 

Ricordiamo nuovamente che sono tutti metodi la cui esecuzione richiede il permesso 
manage_accounts. Da quanto descritto anche attraverso alcuni diagrammi delle attività, la gestione dei 
token presuppone l'utilizzo di una cache, che permette di non creare dei token a ogni richiesta ma di 
riutilizzare lo stesso per un tempo la cui efficacia dipenderà dal tipo di applicazione. Maggiore è la 
sensibilità delle informazioni gestite, minore sarà la durata dei token. La classe AccountManager CI 
offre alcuni metodi che permettono di interagire direttamente con questa cache. Per esempio, 
attraverso 

public String peekAuthToken (Account account, String authTokenType) 

si può ottenere direttamente l'eventuale token, di tipo specificato, memorizzato nella cache se 
disponibile. Va sottolineato come, nel caso di assenza di un token memorizzato, l'invocazione del 
metodo non porterà ad alcuna richiesta esplicita all'utente e ad alcuna interazione con il server di 
autenticazione. Si tratta di una funzionalità che verrà usata prevalentemente dalle implementazioni dei 
sistemi di autenticazione, come del resto quella implementata nel metodo: 

setAuthToken (Account account, String authTokenType, String authToken) 

per la memorizzazione nella cache del token associato a un account. Dagli stessi diagrammi 
possiamo vedere come la cancellazione del token dalla cache porti all'invocazione del server di 
autenticazione, operazione preceduta eventualmente da una richiesta esplicita delle credenziali 
all'utente nel caso di mancata memorizzazione della password. Per eliminare il token dalla cache è 
possibile quindi invocare il metodo 

public void invalidateAuthToken (String accountType, String authToken) 

il quale ha come parametri il tipo di account e il token corrispondente. Questa volta si tratta di 
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un' operazione che necessita di due permessi, ovvero manage_accounts e user_credentials. La 
gestione della password avviene invece attraverso un paio di metodi che richiedono il permesso di 
tipo authenticate_accounts. Il primo permette semplicemente di ottenere il valore della password 
associata a un particolare account: 

public String getPassword (Account account) 

Notiamo come si tratti, all'apparenza, di un metodo potenzialmente pericoloso. Un'applicazione 
che richiedesse il permesso di tipo authenticate_accounts sembrerebbe in grado di accedere alle 
credenziali per utilizzarle in modo non consono. In realtà è un metodo che deve necessariamente 
essere eseguito nello stesso processo del sistema di autenticazione e quindi non da tutte le 
applicazioni. Relativamente alla gestione della password, l'AccountManager ne consente la 
cancellazione attraverso l'invocazione del metodo 

public void clearPassword (Account account) 

oppure la modifica attraverso il metodo 

public void setPassword (Account account, String password) 

È fondamentale ricordare come questi metodi, che richiedono il permesso II 
authenticate_accounts, non cancellano né modificano la password sul server ma solo lo stesso 
valore nella cache locale. Un volta cancellata, l'accesso al servizio richiederà un nuovo inserimento 
esplicito da parte dell'utente. 

Cancellazione di un account 

Dopo aver visto come creare un account e come gestire gli eventuali token, concludiamo la 
descrizione dell' AccountManager con i metodi che permettono reliminazione delle informazioni 
associate a delle credenziali. In questo caso il metodo da utilizzare richiede il permesso 

manage_accounts, ed è il seguente: 

public AccountManagerFuture<Boolean> removeAccount (Account account, 
AccountManagerCallback<Boolean> callback, Handler handler) 

il quale non fa nulla nel caso l'account passato come parametro non esistesse. 

Creare un modulo di autenticazione 
personalizzato 

Come abbiamo visto, l'AccountManager dispone di diversi strumenti che permettono di interagire 
con vari sistemi di autenticazione attraverso la definizione dei concetti di account e di token. Nella 
Figura 13.1 abbiamo poi notato come le diverse applicazioni permettano la definizione di alcuni tipi di 
account che le caratterizzano. Nella stessa figura vediamo infatti account relativi alle applicazioni di 
Google, di GitHub e altre si possono aggiungere semplicemente installando le applicazioni di 
Facebook e Twitter. L'obiettivo di questo paragrafo sarà la realizzazione di un componente che ci 
permetta di gestire gli account di tipo UGHO utilizzando i servizi dummy descritti nella parte iniziale 
del capitolo. Per farlo è necessario seguire alcuni step per la realizzazione di alcuni componenti 
standard, come una specializzazione della classe Abs tract Account Authenticat or del package 
android . accounts, il quale sarà responsabile di tutte le interazioni con i sistemi esterni. 

I passi che seguiremo nella realizzazione di un meccanismo di autenticazione perfettamente 
integrato con la piattaforma Android sono elencati di seguito. 
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1 . Registrazione nel sistema del servizio di autenticazione attraverso documento XML. 

2. Definizione del documento XML relativo agli eventuali parametri di configurazione 
dell'account, come per esempio l'URL del server di autenticazione, che gestiremo attraverso il 
framework delle Preferences. 

3. Creazione di una specializzazione della classe AbstractAccountAuthenticator con 
responsabilità di gestione degli account. 

4. Implementazione di un'activity per l'inserimento esplicito delle credenziali da parte dell'utente. 
È una specializzazione della classe AccountAuthenticatorActivity dello stesso package 

android. accounts. 

5 . Implementazione di un service che metta a disposizione di tutte le applicazioni l'interfaccia 
remota dell' Authenticator. A questo va poi associato un intent con action 

android. accounts. AccountAuthenticator e metadati con riferimento alla descrizione del 
servizio al primo punto. 

Come accennato in precedenza, si tratta di qualcosa di abbastanza complesso, che cercheremo 
comunque di descrivere nel dettaglio passo dopo passo. 

Configurazione dell'Authenticator 

La prima cosa da fare è la creazione di un documento XML che permetta di descrivere il nostro 
modulo al dispositivo e in particolare al framework di gestione degli account. Si tratta di una risorsa di 
tipo XML che chiamiamo ugho_authenticator .xml e inseriamo nella corrispondente cartella res/xml. 
Nel nostro caso il documento è il seguente, in cui abbiamo evidenziato i vari attributi: 

<?xml version="l . 0" encoding="utf-8 " ?> 
occount -authenticator 

xmlns : android="http : // schemas . android . com/ apk/ res/ android" 
android: account Type="uk . co .massimocarli . android. ugho . account . type" 

android: icon=" @drawable/ ic_launcher" 
android : smallIcon=" @drawable/ic_launcher " 
android: label="@string/ugho_authenticator_label" 
android : accountPref erences=" @xml/auth_pref erences " /> 

Si tratta di un unico elemento di nome <account-authenticator/> il cui attributo più importante è 
quello di nome accountType, in quanto ne definisce appunto il tipo. È quella informazione che 
abbiamo utilizzato per ottenere l'elenco degli account di una particolare tipologia nel metodo 
getAccounts ( ) dell' AccountManager. Attraverso l'attributo icon specifichiamo il riferimento all'icona 
che verrà usata per rappresentare il nostro Authenticator alla voce Accounts & Sync Settings (o 
equivalente) delle opzioni del dispositivo. La versione ridotta, impostata attraverso l'attributo 
smaii icon, è invece l'icona che permetterà di riconoscere tra i contatti quelli provenienti dal nostro 
sistema remoto. L'attributo label farà riferimento al nome del nostro Authenticator ttl 
configurazione, mentre più importante è il significato dell'attributo accountPref erences. Esso fà 
riferimento a un documento XML che consente di descrivere quelli che saranno gli eventuali parametri 
di configurazione dell' authenticator. Nel nostro caso, nel punto successivo, creeremo una piccola 
interfaccia che permetterà di inserire il valore del server a cui connettersi per l' autenticazione. 
Vediamo che anche questo file, di nome auth_ P ref erences .xml, è contenuto nella cartella dedicata 
alle risorse XML, ovvero res/xml. Per non dimenticarci è importante iniziare a memorizzare i valori 
che caratterizzano i nostri account attraverso delle opportune costanti di una classe che abbiamo 
chiamato Accountconst, e che abbiamo messo nel package account relativo a quello 
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dell'applicazione. In questa fase abbiamo definito la costante relativa al tipo di account, ovvero: 

public static final String UGHO_ACCOUNT_TYPE = 

"uk . co .massimocarli . android. ugho . account " ; 

Definizione XML dei parametri di configurazione del servizio 

Nel punto precedente abbiamo descritto il sistema di autenticazione al dispositivo e abbiamo 
indicato, attraverso l'attributo accountPref erences, la risorsa contenente la configurazione delle 
preferenze da associare al'Authenticator. In questa fase dobbiamo fare molta attenzione in quanto 
dovremo creare almeno due documenti XML. Il primo consentirà di descrivere al framework degli 
account quali sono le categorie di configurazione. Infatti un account potrebbe essere configurabile 
sotto diversi aspetti, come quello legato al server di accesso (come il nostro) oppure ai colori da 
utilizzare nell'applicazione. Questo primo documento XML dovrà necessariamente avere la struttura 
che abbiamo definito nel file chiamato auth_ P ref erences .xml e che nel nostro caso è la seguente: 

<?xml version="l . 0" encoding="utf-8" ?> 

<Pref erenceScreen xmlns : android="http : / / schema s . android . com/apk/ re s /android" > 
<Pref erenceCategory android : title=" @strìng/ugho_auth_category_label " / > 
<Pref erence 

android: summary=" @ string/ ugho_auth_server_message" 
android: title=" @string/ugho_authenticator_label "> 

<intent android: action="uk . co .massimocarli . android. ugho . action . SHOW_PREFS"/> 

</Pref erence> 
</PreferenceScreen> 

Si tratta del file a cui l'attributo accountPref erences farà riferimento nel file di configurazione 
dell' Authenticator. Notiamo come debba comprendere una serie di definizioni della categoria di 
riferimento e un elemento <pref erence>, il quale contiene al suo intemo un altro elemento di tipo 
<intent/> che descrive appunto l'intent che dovrà essere lanciato al momento della selezione. Anche 
in questa fase dobbiamo stare molto attenti in quanto non possiamo, come erroneamente riportato in 
diversi siti, definire l'activity di destinazione in modo esplicito, ma dobbiamo definire un'opportuna 
action a cui poi risponderà la corrispondente attività di configurazione. Questo, in base a quanto 
detto, è necessario in quanto l'applicazione di gestione degli account è in esecuzione in un processo 
diverso da quello della nostra applicazione nella quale è contenuta l'activity di destinazione. Nel 
nostro caso tale activity è descritta dalla classe 

public class UghoAccountPref erenceActivìty extends SherlockPref erenceActivity { 

SSuppressWarnings ( "deprecation" ) 
SOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

addPref erencesFromResource (R . xml . auth_server_settings ) ; 

} 

} 

che è molto semplice e utilizza un documento XML di configurazione come il seguente, che 
abbiamo messo nel file auth_server_settings . xml. 
<?xml version="l . 0" encoding="utf-8" ?> 

<Pref erenceScreen xmlns : android="http : // schemas . android. com/apk/ res/android"> 
<Pref erenceCategory android: title=" @string/ugho_auth_category_label " / > 
<EdìtTextPref erence 

android: key="server_uri_key" 

android: title=" @ string/ ugho_auth_server_label" 

android: dialogIcon="@drawable/ic_launcher " 

android: dialogTitle="@string/ugho_auth_server_label" 

android : dialogMessage=" @string/ugho_auth_server_message" /> 
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</Pref erenceScreen> 

Questo consente l'inserimento dell'URI associandolo alla chiave di nome evidenziata. Nel nostro 
caso Fattività è descritta dalla classe UghoAccountPref erenceActivity, che estende 
sheriockPref erenceActivity inmodo da costruire automaticamente l'interfaccia grafica dal 
precedente file XML. Non dobbiamo dimenticarci di definire l'activity nell'I ndroidManif est . xml 
come segue: 

Octivity android: name=" . account . UghoAccountPref erenceActivity "> 
<intent-f ilter> 

<action android : name="uk . co .massimocarli . android . ugho . action . SHOW_PREFS" /> 

<category android: name=" android. intent . category . DEFAULT" /> 
</intent-filter> 
</ activity> 

Il risultato di quanto descritto è quello nella Figura 13.4 per la visualizzazione delle categorie di 
configurazione e quello nella Figura 13.5 quando si seleziona la categoria relativa al server di 
autenticazione. 
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Figura 13.4 Le diverse categorie relative alla configurazione dell'account. 
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Figura 13.5 Opzione di editing del server di autenticazione. 



Partendo dalla Figura 13.5 è possibile editare il valore associato alla chiave s erver_uri_key. 
Un'ultima osservazione riguarda il tatto che, nel nostro caso, si tratta di una configurazione non legata 
al profilo ma di carattere generale. Sta alla nostra implementazione legare o meno tali informazioni al 
particolare profilo. 



Implementazione dell'AccountAuthenticator per la creazione 

di un account 

Siamo così giunti alla parte più importante della realizzazione del nostro sistema personalizzato di 
gestione degli account, ovvero la creazione di una particolare specializzazione della classe 
AbstractAccountAuthenticator del package android . account s. E quel componente che, come 
vedremo, contiene la logica di accesso al server in corrispondenza delle operazioni che abbiamo 
descritto relativamente all'AccountManager . Per una buona comprensione del funzionamento della 
classe che abbiamo chiamato ughoAuthenticator, è necessario trattare anche Fattività di interazione 
con l'utente che abbiamo invece descritto nella classe ugnoAutnActivity. Come detto, il nostro 
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ughoAuthenticator estende la classe ibstractkccountAuthenticator, che dispone di un unico 
costruttore che ha come unico parametro il riferimento al Context. Come sappiamo, in Java ogni 
classe ha sempre il costruttore di de fault (quello senza parametri). Si tratta di un costruttore pubblico 
quando la classe è pubblica e con visibilità di default quando anche la classe ha questa visibilità. 
Questo costruttore di default viene però perso non appena si definisce un costruttore diverso, ovvero 
con parametri. In questo caso, se si desidera mantenere il costruttore di default occorre definirlo in 
modo esplicito. Se la nostra classe ughoAuthenticator non definisse alcun costruttore si 
verificherebbe un errore di compilazione. Infatti, in quel caso, la classe avrebbe un costruttore di 
default equivalente alle seguenti righe di codice: 

public UghoAuthenticator ( ) { 
super () ; 

} 

Ogni costruttore di default chiama, come prima cosa, il costruttore di default della classe padre, 
che nel nostro caso non esisterebbe. La nostra implementazione del costruttore diventa allora la 
seguente 

public UghoAuthenticator ( final Context context) { 
super (context ) ; 
this .mContext = context; 

} 

dove approfittiamo del parametro richiesto per salvare in locale il riferimento al Context. 
La prima operazione che abbiamo implementato è quella relativa alla creazione di un account, 
operazione che richiede sempre la richiesta esplicita delle credenziali all'utente: 

SOverride 

public Bundle addAccount (AccountAuthenticatorResponse response, 

Strìng accountType, String authTokenType, Stringi] requiredFeatures , 
Bundle options) throws NetworkErrorException { 
Intent loginlntent = new Intent (mContext, UghoAuthActivity . class ) ; 
loginlntent .putExtra (AccountManager . KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, 
response) ; 

loginlntent .putExtra (UghoAuthActivity . ACCOUNT_TYPE_P ARAM, 

AccountConst . UGHO_ACCOUNT_TYPE) ; 
loginlntent .putExtra (UghoAuthActivity . TOKEN_TYPE_P ARAM, 

AccountConst . UGHO_TOKEN_TYPE) ; 
Bundle returnBundle = new Bundle (); 

returnBundle . putParcelable (AccountManager . KEY_INTENT , loginlntent ) ; 

return returnBundle; 

} 

Come possiamo vedere, si tratta di un'operazione che ha tra i propri parametri molti di quelli 
passati nell'omonima operazione della classe AccountManager. L'aspetto fondamentale di questo 
metodo, comune anche ai successivi, è quello di prevedere sia una modalità sincrona sia una 
asincrona. Nel primo caso il risultato dell'operazione dovrà essere ritornato attraverso un oggetto 
Bundle contenente, in caso di successo, le informazioni relative al nome dell'account e al tipo associati 
a opportune chiavi che ritroviamo come costanti della classe AccountManager. In caso di errore 
inseriremo la corrispondente informazione sempre nello stesso Bundle associata a una chiave diversa 
dalle precedenti. La modalità che invece abbiamo seguito nella nostra implementazione è quella 
asincrona, che prevede l'utilizzo dell'oggetto di tipo AccountAuthenticatorResponse passato come 
primo parametro. Qui il Bundle di ritorno non dovrà contenere il risultato dell'operazione ma il 
riferimento all' intent da lanciare per la visualizzazione dell' activity di richiesta delle credenziali 
all'utente. Questo intent dovrà essere associato alla chiave relativa alla costante 
AccountManager. key_intent, come abbiamo evidenziato nel codice precedente. L'attività lanciata 
dovrà poi utilizzare l'oggetto di tipo AccountAuthenticatorResponse per la notifica del risultato, per 
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cui è necessario inserire il suo riferimento nell'intent, associandolo alla costante 
AccountManager . key_account_authenticator_response. Possiamo notare come Factivity venga 
invocata in modo esplicito e come a essa vengano passate anche le informazioni relative al tipo di 
account e al tipo di token. In questo caso le costanti che abbiamo usato come chiave non sono 
previste dal framework ma sono state dichiarate all'interno della nostra classe Account Const. 
Riassumendo, abbiamo ritornato un Bundie contenente l'intent per la visualizzazione dell'attività di 
richiesta esplicita delle credenziali all'utente. A questa attività abbiamo passato le informazioni relative 
al tipo di account, al tipo di token ma soprattutto il riferimento all'oggetto che la stessa activity 
utilizzerà per la notifica del risultato. Nel caso in cui avessimo potuto verificare l'utente, avremmo 
potuto già in questa implementazione creare l'account e quindi ritornare unBundie di successo. 

In fase di creazione dell'account andiamo allora a esaminare la nostra classe tghoAuthActivity, 
notando da subito che è una specializzazione della classe di utilità Kc countAuthenticat or Activity 
dell'ambiente Android. Non serve estendere questa classe per la realizzazione di attività di questo 
tipo, ma essa ci semplifica, come vedremo, la restituzione del risultato attraverso l'oggetto 

AccountAuthenticatorResponse passato dal CustomAuthenticator. 

Notiamo anche che la classe AccountAuthenticatorResponse non estende le classi di 
ActionBarSheriock, per cui talvolta si rende necessaria la creazione di un'implementazione 
personalizzata che nel nostro caso abbiamo definito nella classe 

AccountAuthenticatorFragmentActivity, che è comunque molto semplice: 

public class AccountAuthenticatorFragmentActivity extends 

SherlockFragmentActivity { 

private AccountAuthenticatorResponse mAccountAuthenticatorResponse = nuli; 

private Bundle mResultBundle = nuli; 

protected void onCreate (Bundle icicle) { 
super . onCreate (icicle) ; 

mAccountAuthenticatorResponse = getlntent() 

. getParcelableExtra (AccountManager 

. KEY_ACCOUNT_AUTHENTICATOR_RESPONSE) ; 
if (mAccountAuthenticatorResponse != nuli) { 

mAccountAuthenticatorResponse . onRequestContinued ( ) ; 

} 

} 

public final void setAccountAuthenticatorResult (Bundle result) { 
mResultBundle = result; 

} 

public void finish () ( 

if (mAccountAuthenticatorResponse != nuli) { 
if (mResultBundle != nuli) { 

mAccountAuthenticatorResponse . onResult (mResultBundle) ; 
} else { 

mAccountAuthenticatorResponse 

. onError (AccountManager. ERROR_CODE_CANCELED , "canceled") ; 

} 

mAccountAuthenticatorResponse = nuli; 

} 

super . finish ( ) ; 

} 

} 

Nelle parti evidenziate notiamo in che modo venga gestito l'oggetto di tipo 

AccountAuthenticatorResponse passato attraverso l'extra di nome 
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KEY_AccouNT_AUTHENTicATOR_fcESPONSE sia in fase di creazione, e quindi nel metodo oncreate o, sia 
in quella di chiusura, e quindi di finish ( ) . 

Per descrivere l'attività di inserimento delle credenziali (che ora estende la precedente classe 

AccountAuthenticatorFragmentActivity) iniziamo dall'implementazione del metodo onCreate o : 
SOverride 

protected void onCreate (Bundle icicle) { 
super . onCreate (icicle) ; 

setContentView (R. layout . activity_login) ; 
mAccountManager = AccountManager . get (this ) ; 

mUsernameEditText = (EditText) f indViewByld (R. id.username_edittext) ; 
mPasswordEditText = (EditText) f indViewByld (R. id. password_edittext ) ; 
mErrorTextView = (TextView) f indViewByld (R . id. error_message_label ) ; 
Intent requestlntent = getlntent(); 

String username = requestlntent . getStringExtra (USERNAME_P ARAM) ; 
mlsNewAccount = TextUtils . isEmpty (username) ; 
if (! mlsNewAccount ) { 

mUsernameEditText . setText (username) ; 

} 

mAuthTokenType = requestlntent . getStringExtra (TOKEN_TYPE_P ARAM) ; 
mlsCredentialConf irm = requestlntent 

. getBooleanExtra (CONFIRM_CREDENTIAL_PARAM, false) ; 

} 

Il lettore potrà notare da subito come si tratti di un'activity molto simile a quella descritta dalla 
classe LoginActivity che abbiamo utilizzato nella nostra implementazione iniziale. Si tratta infatti dello 
stesso codice e layout che abbiamo adattato per la comunicazione con lo UghoAuthenticator. 

A parte l'immancabile richiamo allo stesso metodo della classe padre, e la gestione del componenti 
grafici dell' interfaccia, vediamo come si ottenga il riferimento all' intent di attivazione attraverso il 
metodo getintent o e l'estrazione da esso di alcune delle informazioni impostate nel precedente 
metodo addAccount ( ) . Questa attività non verrà utilizzata solamente in fare di creazione di un account 
ma anche in fase di verifica dello stesso. Per questo motivo il primo controllo riguarda la presenza 
nel' intent e dele informazioni relative al nome del' account che abbiamo associato alla variabfle 

username. 

Questo perché nel caso di assenza di questa informazione l'operazione richiesta al'activity sarà 
quella di creazione di un nuovo account, mentre in caso di presenza si tratterà di un'operazione di 
verifica o conferma. Attraverso la variabfle misCredentiaiconf irm gestiamo invece una richiesta 
esplcita di verifica anche nel caso in cui lo username sia specificato. Al' intemo di questo metodo 
otteniamo anche il riferimento al'iccountManager per eseguire, in caso diconvalda, la registrazione 
esplcita del' account attraverso il metodo addAccountExpiicitiy o esaminato in precedenza. 
L'interfaccia di questa attività è quella nella Figura 13.6 e prevede l'inserimento dele credenzial e 
quidi la selezione del' opzione di logjn. 
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Username: 



Password: 



Figura 13.6 Interfaccia per la creazione dell'account. 

Alla funzione di login è associata l'esecuzione del metodo doLogin ( ) , la cui responsabilità è quella 
di interagire con il server di autenticazione. La logica di questo metodo è quella nel diagramma delle 
attività nella Figura 13.7, che descriviamo nel dettaglio. 

Inizialmente eseguiamo una verifica formale relativa alla presenza o meno delle informazioni relative 
a username e password. L'assenza di queste informazioni causerà la visualizzazione di un messaggio di 
errore quindi il ritorno al punto dipartenza. Una volta inseriti dei valori, la selezione dell'opzione di 
login porta all'esecuzione di una richiesta al server che, nel codice allegato, abbiamo implementato 
usando il framework Volley allo stesso modo di quanto fatto in precedenza tranne per la gestione del 
risultato nel caso di successo (in caso di errore visualizzeremo un messaggio di errore). 
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Figura 13.7 Diagramma di flusso per la gestione del processo di autenticazione. 

Per come abbiamo definito il protocollo di comunicazione, unlogin porta alla restituzione di un 
JSON del seguente tipo 

{ 

result: "OK", 
username: "pippo", 
email: "pippo@pippo.com", 
birthDate: 672346738678, 
location: "London", 
token: "my_token" 

} 

in caso di successo o 



result: "KO", 

message: "wrong credentials" 



in caso di làllimento. Per un migliore incapsulamento delle informazioni abbiamo poi creato il 
seguente metodo nella classe UserModel, il quale ci permette di leggere le informazioni di un 
documento JSON e valorizzare le opportune proprietà del nostro modello: 

public static UserModel fromJson ( final JSONObject jsonObj) { 
UserModel userModel = nuli; 

final Strìng result = jsonObj . optString ( "result " , 

AccountConst .KO_RESULT) ; 
ìf (AccountConst. KO_RESULT . equals (result) ) { 

userModel = UserModel . f romError ( jsonObj . optString ( "message" ) ) ; 
} else { 

final long birthDate = j sonObj . optLong ( "birthDate" , 0); 
if (birthDate > 0) { 

userModel = UserModel . create (birthDate) 
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. withEmail ( jsonOb j . optString ( "email" ) ) 

. withUsername ( jsonOb j . optString ( "use marne" ) ) 

. withLocation ( jsonOb j . optString ( "location" ) ) ; 

} else { 

userModel = UserModel . f romError ( "Error in birthDate data!"); 

} 

} 

return userModel; 

} 

Notiamo come si verifichi il valore dell'attributo resuit per poi valorizzare le proprietà in caso di 
successo o il messaggio di errore in caso contrario. Se l'autenticazione è avvenuta con successo 
dovremo lare in modo di rispondere all'Authenticator attraverso l'oggetto di tipo 
Account AuthenticatorResponse. Lasciando al lettore la visione del codice relativo alla lettura e 
validazione dei campi di input, ci concentriamo sull'invio della richiesta e sull'elaborazione del 
risultato. Il tutto è all'interno dei metodi di callback di una richiesta eseguita con il framework Volley: 

final String loginUrl = getResources ( ) . getString (R. string . login_url, 

username, MD5Utìlity .md5 (password) ) ; 
JsonOb jectRequest jsObjRequest = new JsonOb jectRequest (Request .Method. GET, 
loginUrl, nuli, 

new Response . Lìstener< JSONOb ject> ( ) { 

SOverride 

public voìd onResponse ( JSONObject response) { 

// Gestione della risposta 
}, new Response . ErrorListener ( ) { 

SOverride 

public voìd onErrorResponse (VolleyError error) { 
// Gestione dell'errore 

} 

}) ; 

mProgressAlertDialog = new ProgressAlertDialog ( ) ; 

mProgressAlertDialog . show (getSupportFragmentManager ( ) , PROGRE S S_D I ALOG_TAG ) ; 
requestQueue . add ( jsObjRequest ) ; 

Dopo aver ottenuto l'URL di connessione eseguiamo una richiesta di tipo tsonob jectRequest, 
fornendo quindi implementazione dei metodi onResponse ( ) e InErrorResponse ( ) per la gestione 
rispettivamente del successo e del fallimento della richiesta stessa. Il caso di successo è il più 
interessante perché corrisponde alla creazione dell'account. Nel nostro caso le istruzioni che abbiamo 
utilizzato sono molto semplici e precisamente: 

mProgressAlertDialog . dismiss () ; 

UserModel userModel = UserModel . fromJson (response) ; 
if (userModel != nuli && ! userModel . hasError () ) { 
final Account account = new Account (username, 
AccountConst .UGHO_ACCOUNT_TYPE) ; 

if (mlsNewAccount ) { 

Bundle initBundle = userModel . toBundle () ; 

mAccountManager . addAccountExplicitly (account , password, initBundle) ; 
} else { 

mAccountManager . setPassword (account, password) ; 

} 

final Intent resultlntent = new Intento; 

resultlntent .putExtra (AccountManager . KEY_ACCOUNT_NAME, username) ; 
resultlntent .putExtra (AccountManager . KEY_ACCOUNT_TYPE, 

AccountConst .UGHO_ACCOUNT_TYPE) ; 
final String accessToken = response . optString ( "token" ) ; 

if (! TextUtils . isEmpty (accessToken) && TextUtils . isEmpty (mAuthTokenType) 
&& mAuthTokenType. equals (AccountConst. UGHO_TOKEN_TYPE) ) { 
resultlntent .putExtra (AccountManager . KEY_AUTHTOKEN, accessToken) ; 

} 

setAccountAuthenticatorResult (resultlntent .getExtras () ) ; 
setResult (RESULT_OK, resultlntent) ; 
finish () ; 
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} else { 

mErrorTextView . setText (userModel . getErrorMessage ( ) ) ; 
mErrorTextView. setvisibility (View. VISIBLE) ; 

} 

Innanzitutto vediamo come il parametro del metodo dicallback onResponseo contenga già un 
oggetto di tipo jsoNOb ject corrispondente alla risposta dal server. In questa làse è bene lare una 
precisazione in relazione a che cosa si intenda per errore. L'errore inteso da Volley è quello relativo a 
un codice di risposta HTTP non del tipo 2xx come 200 o 20 1 . Si tratta per esempio di un codice 
404 dovuto a un errato URL di chiamata o a un errore 500 relativo a un crash lato server. Il latto 
però che la richiesta HTTP abbia portato a una risposta positiva non significa che l'utente è loggato, in 
quanto è necessario verificare il valore dell'attributo resuit. Come accennato in precedenza abbiamo 
deciso di incapsulare la logica di parsing del JSON di risposta dall'operazione di login all'interno di un 
metodo di utilità della stessa classe userModei: 

public statìc UserModel fromJson ( final JSONObject jsonObj) { 
UserModel userModel = nuli; 

final String resuit = jsonObj . optString ( "resuit " , 

AccountConst .KO_RESULT) ; 
if (AccountConst. KO_RESULT . equals (resuit) ) { 

userModel = UserModel . f romError (jsonObj . optString ( "message" ) ) ; 
} else { 

final long birthDate = j sonOb j . optLong ( "birthDate" , 0); 
if (birthDate > 0) { 

userModel = UserModel . create (birthDate) 

. withEmail ( jsonObj . optString ( "email" ) ) 

. withUsername ( jsonObj . optString ( "use marne" ) ) 

. withLocation ( jsonObj . optString ( "location" ) ) ; 

} else { 

userModel = UserModel . f romError ( "Error in birthDate data!"); 

} 

} 

return userModel; 

} 

Notiamo come si legga il valore dell'attributo "resuit" per capire se la risposta corrisponda a 
un'operazione di login avvenuta con successo oppure no. In questo modo abbiamo anche incapsulato 
i nomi degli attributi che avremmo potuto definire all'interno di altrettante costanti statiche. 

Il metodo di utilità appena descritto viene usato per estrarre gli attributi dalla risposta JSON 
ritornandoli all'interno di un oggetto di tipo userModel. Nel caso di successo il campo error rimarrà 
vuoto, per cui il metodo hasError ( ) ritornerà un valore false e potremo procedere con la creazione 
dell'account, il quale è contraddistinto da un'istanza della classe Account. Ciascuno di questi è 
caratterizzato da un nome e un tipo. Il nome corrisponde allo username dell'utente (ma potrebbe 
corrispondere anche ad altre informazioni obbligatorie), mentre il tipo è quello che abbiamo fissato 
per il nostro sistema e che abbiamo definito attraverso la costante ugho_account_type della classe 
AccountConst. Come abbiamo visto in precedenza, la nostra activity contiene una variabile d'istanza 
di nome misNewAccount, che ci permette di sapere se siamo nel caso di creazione di un nuovo 
account o di validazione di imo esistente. Quest'ultima si potrebbe essere resa necessaria a seguito di 
un cambio password lato server (che quindi ha invalidato quella memorizzata eventualmente in locale) 
oppure dell'invalidazione deltoken. 

Nel caso in cui l'account sia nuovo dobbiamo ricorrere al metodo di creazione esplicita, con le 
seguenti istruzioni; 

Bundle initBundle = userModel . toBundle () ; 

mAccountManager . addAccountExplicitly (account , password, initBundle) ; 

Dopo la creazione dell'account, è stato utilizzato il metodo addAccountExplicitly o per la 
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memorizzazione dello stesso nel nostro sistema. I parametri sono il nome dell'account a cui segue la 
password e un oggetto di tipo Bundie, che è molto importante in quanto contiene l'insieme di quelle 
informazioni, necessariamente di tipo string, da associare al particolare account. Nel nostro caso 
abbiamo infatti definito un metodo di utilità toBundie o in grado di salvare lo stato dello userModei in 

Un Bundlel 

public Bundle toBundleO { 

Bundle bundle = new Bundle (); 

bundle .putString (BIRTHDATE_KEY, String . valueOf (mBirthDate) ) ; 
bundle .putStrìng (EMAIL_KEY, mEmail) ; 
bundle .putString (LOCATION_KEY, mLocation) ; 
return bundle; 

} 

Qualora l'account fosse solo da convalidare non dovremo far altro che aggiornare le informazioni 
corrispondenti attraverso la seguente istruzione: 

mAccountManager . setPassword (account, password) ; 

Notiamo infatti come questo tipo di informazioni non si imposti sull'oggetto di account ma 
utilizzando specifici metodi della classe AccountManager. 

A questo punto l'account è stato creato oppure aggiornato a seconda dei casi La fase successiva 
consiste nella notifica di quanto avvenuto all'Authenticator da cui la nostra activity era stata lanciata 
anche se in modo indiretto. Il meccanismo è un po' laborioso ma non difficile e consiste nella 
creazione di un intent con queste informazioni: 

final Intent resultlntent = new Intento," 

resultlntent .putExtra (AccountManager . KEY_ACCOUNT_NAME, username) ; 
resultlntent .putExtra (AccountManager . KEY_ACCOUNT_TYPE, 
AccountConst . UGHO_ACCOUNT_TYPE) ; 

Attraverso delle opportune costanti statiche definite nella classe AccountManager impostiamo i 
valori relativi al nome dell'account e al tipo. Si tratta infatti delle informazioni di cui 1' Authenticator 
necessita per dichiarare valida l'operazione di creazione dell'account. 

Nel nostro caso il server ritorna anche il valore del token che andiamo a leggere e quindi a 
memorizzare all'interno del nostro account attraverso le istruzioni 

final String accessToken = response . optString ( "token" ) ; 

if (! TextUtils . isEmpty (accessToken) && TextUtils . isEmpty (mAuthTokenType) 
SS mAuthTokenType. equals (AccountConst . UGHO_TOKEN_TYPE) ) { 
resultlntent .putExtra (AccountManager . KEY_AUTHTOKEN, accessToken) ; 

} 

Notiamo come il valore del token venga impostato nel nostro intent attraverso la costante 
AccountManager . key_authtoken e solamente nel caso in cui sia presente e di tipo corrispondente a 
quello impostato per la nostra implementazione. 

Concludiamo con il passaggio dell' intent appena valorizzato al componente chiamante attraverso 
poche righe di codice: 

setAccountAuthenticatorResult (resultlntent .getExtras () ) ; 
setResult (RESULT_OK, resultlntent) ; 
finish ( ) ; 

Nel nostro caso abbiamo fatto in modo che la classe ughoAuthActivity estendesse una classe che 
gli mettesse a disposizione gli stessi metodi della classe AccountAuthenticatorActivìty ma in modo 
compatibile con l'utilizzo di ActìonBarSheriock. Per questo motivo, anche la nostra activity ha la 
possibilità di utilizzare il metodo 

public final void setAccountAuthenticatorResult (Bundle result) 

È il metodo che ci permette di inserire l'insieme delle informazioni dell'account appena creato 
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all'interno dell'oggetto di tipo AccountAuthenticatorResponse per poterlo poi ritornare al 
componente chiamante. Notiamo come il riferimento a tale oggetto per la risposta sia avvenuto in 
precedenza attraverso un extra legato alla costante key_account_|\uthenticator_response 
dell' AccountManager. Non ci resta che comportarci come se questa activity fosse state chiamata a 
seguito di una chiamata al metodo startActivityForResuit o .Abbiamo quindi impostato come 
valore di ritorno l'intent come quello associato a un OK e all'invocazione di finish ( ) per terminare 
F activity, che quindi verrà chiusa. 

Concludiamo il paragrafo facendo notare come, nel caso di un errore nella risposta del servizio di 
autenticazione, non faremo altro che visualizzare il messaggio corrispondente nella relativa Textview. 

Creazione del service di autenticazione 

Nel paragrafo precedente abbiamo implementato il metodo addAccount o del nostro 
Autenticator che abbiamo descritto attraverso la classe ughoAuthenticator. Prima di trattare altri 
aspetti legati alla gestione degli account vogliamo vedere qualcosa che funziona, e quindi creare un 
account utilizzando il meccanismo standard di creazione degli account tra i Settings della piattaforma. 
L'insieme delle classi che abbiamo realizzato non è al momento sufficiente. Abbiamo già visto che si 
tratta di un framework condiviso tra più applicazioni, ciascuna delle quali viene eseguita all'interno di 
processi diversi Quando componenti in esecuzione in processi diversi devono scambiarsi delle 
informazioni, Android ricorre a meccanismi di IPC (Inter Process Communication). Questo significa 
che le operazioni che il nostro specifico Authenticator implementa dovranno essere messe a 
disposizione delle altre applicazioni attraverso un'interfaccia remota; è una feature che la nostra classe 
ughoAuthenticator eredita dal fatto di estendere AbstractAccountAuthentìcator, la quale dispone 
del metodo 

public final IBinder getIBinderO 

che consente di ottenere il proxy per l'accesso alle sue funzionalità da un processo diverso. Per 
mettere a disposizione delle altre applicazioni il proxy così ottenuto è quindi necessaria la realizzazione 
di un service la cui implementazione non farà altro che ritornare lo stesso proxy in corrispondenza di 
un'operazione digestione degli account. Ecco l'implementazione del nostro servizio, descritto dalla 
classe UghoAuthService; 

public class UghoAuthService extends Service { 

private UghoAuthenticator mUghoAuthenticator; 

public void onCreate () { 

mUghoAuthenticator = new UghoAuthenticator (this) ; 

} 

public void onDestroyO { 

mUghoAuthenticator = nuli; 

} 

public IBinder onBìnd ( Intent intent) { 

return mUghoAuthenticator . get IBinder () ; 

} 

} 

Possiamo vedere come la sua unica responsabilità sia quella di ritornare il proxy relativo ai servizi 
del nostro ughoAuthenticator. Per fare in modo che questo servizio risponda alle sollecitazioni 
conseguenti l'esecuzione delle operazioni di gestione degli account, le convenzioni prevedono che lo 

SteSSO venga definito nell'AndroidManifest.xmi: 
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<service android: name=" . account . UghoAuthService " 
android : exported="true"> 
<intent-f ilter> 

<action android: name=" android. account s . Account Authenticator"/> 

</intent-f ilter> 
<meta-data 

android: name="android. accounts . AccountAuthenticator" 
android: resource=" @xml/ugho_authenticator " / > 
</ service> 

senza dimenticarsi di aggiungere il corrispondente permesso, ovvero: 

<uses-permission android: name=" android. permi ss ion . GET_ACCOUNTS"/> 
<uses-permission android : name=" android. permi ss ion . AUTHENTICATE_ACCOUNTS" /> 

Come evidenziato, è necessario che il servizio risponda all'azione associata al valore 
android. accounts .AccountAuthenticator e abbia un elemento <meta-data/> che contenga il 
riferimento al documento XML creato all'inizio del nostro lavoro. Si tratta di quel documento XML 
che descrive il sistema personalizzato di gestione degli account al dispositivo. Di fondamentale 
importanza è la presenza dell'attributo android : exported, il quale permette di làr sì che anche le altre 
app Reazioni possano interagire con il servizio attraverso l'invio di un intent corrispondente al relativo 
intent filler. Altra informazione importante riguarda, infine, il nome del processo in cui il servizio verrà 
eseguito, a cui noi abbiamo assegnato il valore : authentication. Ricordiamo che tale nome deve 
iniziare con i due punti (:). 

NOTA 

Quella del processo alternativo è una configurazione opzionale che dipende da quella che è la 
sinergia del modulo di autenticazione con le altre applicazioni correlate. 

A questo punto tutto sembra pronto per la creazione di un account con il nostro nuovo 
meccanismo di autenticazione basato sull' AccountManager di Android, come vedremo nel prossimo 
paragrafo. 

Creazione di un account 

Dopo quanto realizzato siamo già in grado di testare il nostro codice e creare un primo account. 
NOTA 

Qui utilizzeremo un Nexus 4, per cui la procedura potrebbe essere leggermente diversa in altri 
dispositivi come per esempio il Galaxy S3 ed S4. La successione delle operazioni sarà comunque 
sostanzialmente la stessa. 

Andiamo miSettings del dispositivo attraverso l'app Reazione corrispondente oppure passando 
per ilpanneRo deRe no tifiche (Figura 13.8). 
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Figura 13.8 Schermata di creazione degli account. 

Selezioniamo il pulsante + (Aggiungi account) ottenendo la schermata nella Figura 13.9, nella 
quale sono elencati tutti i possibili tipi di account relativi alle applicazioni installate nel dispositivo. 
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Figura 13.9 Elenco dei possibili account tra cui anche UGHO. 



Nella Figura 13.9 notiamo la presenza di diversi tipi di account tra cui anche quello che abbiamo 
realizzato per l'applicazione, selezionandolo otteniamo la schermata relativa al nostro login, che 
abbiamo già visto nella Figura 13.6. A questo punto inseriamo le credenziali, che per il nostro test 
ricordiamo essere pippo/android e quindi selezioniamo l'opzione di invio. Nel caso di login corretto 
l'attività termina e si ritorna alla schermata degli account della Figura 13.10, dove vediamo anche 
quello appena creato. 



552 



<D Backup e ripristino 

ACCOUNT 

0 GitHub 

8 Google 

w MailOnLine 
$ UG HO Account 
+ Aggiungi account 

SISTEMA 



Figura 13.10 Aggiunta del nostro account tra quelli creati nel dispositivo. 

A questo punto l'account è creato, per cui selezioniamo l'elemento corrispondente nella 
precedente lista ottenendo quanto mostrato nella Figura 13.11, che avevamo già visto in precedenza 
ma che riprendiamo per sottolineare la presenza di un modulo di sincronizzazione. Una delle principali 
caratteristiche del framework di gestione degli account di Andro id è infatti la possibilità di legarlo a un 
meccanismo di sincronizzazione. Un esempio tipico di questo sistema è quello dei contatti, che 
vengono sincronizzati con i corrispondenti server proprio attraverso un meccanismo di questo tipo. 
Vedremo più avanti come legare la sincronizzazione delle misure a un account attraverso un sistema 
analogo. 
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Figura 13.11 Informazioni legate all'account creato. 

In questo esempio abbiamo creato l'account a partire dai Settings del dispositivo. Il passo 
successivo consiste nella creazione di un account a partire dalla nostra applicazione. A tale proposito 
dobbiamo modificare la classe FirstAooessActivity, e in particolare l'implementazione del metodo 
doLogin ( ) , il quale dovrà utilizzare l'AccountManager nel seguente modo: 

public void doLogin(){ 

mAocountManager .addAccount (AccountConst .UGHO_ACCOUNT_TYPE, 
AccountConst . UGHO_TOKEN_TYPE, nuli, nuli, 
this, new AccountManagerCallback<Bundle> ( ) { 

public void run (final AccountManagerFuture<Bundle> amf) { 
Bundle result = nuli; 
try { 

result = amf . getResult ( ) ; 
} catch (Exception e) { 
e . printStackTrace ( ) ; 

} 

if (result != nuli) { 

final String accountName = 

result .getString (AccountManager . KEY_ACCOUNT_NAME) ; 
if (accountName != nuli) { 
final String accountType = 

result .getString (AccountManager . KEY_ACCOUNT_TYPE) ; 
final Account newAccount = 

AccountUtility . f indAccountByNameAndType (FirstAccessActivity . this , 
accountName, accountType) ; 
final UserModel userModel = 

UserModel . fromAccount (FirstAccessActivity . this, newAccount) ; 



554 



userModel . save (First AccessActivity . this) ; 

final Intent mainlntent = new Intent (FirstAccessActivity . this, 

MenuActivity . class) ; 
startActivity (mainlntent ) ; 
finish ( ) ; 

} 

} 

} 

} , mBgHandler ) ; 

} 

Innanzitutto notiamo come questo avvenga attraverso l'invocazione del metodo IddAccount o 
della classe AccountManager, che abbiamo descritto nella parte iniziale del capitolo. Prima di 
proseguire non dobbiamo dimenticarci che si tratta di un metodo che necessita del permesso 

android.permission.MANAGE_ACCOUNTS 

che andiamo ad aggiungere al nostro AndroidManifest.xmi. Come accennato in precedenza, 
questo metodo offre due modalità: sincrona e asincrona. Nel nostro caso scegliamo la seconda, che 
prevede l'utilizzo di un handler nel cui thread verrà invocato il metodo run ( ) dell'oggetto 
AccountManagerCaiiback passato come parametro. Ricordiamo infatti che, secondo questa modalità, 
il risultato verrà passato come parametro di tipo AccountManager Future<Bundle> del metodo run ( ) 
dell'interfaccia dicallback. Per non impegnare il thread principale abbiamo quindi bisogno di passare 
un handler diverso da quello che avremmo nel caso istanziassimo semplicemente F omonima classe 
neU'activity. Per questo motivo abbiamo creato un handler diverso attraverso le seguenti poche righe 
che abbiamo messo nel metodo oncreate o dell' activity: 

final HandlerThread mHandlerThread = new HandlerThread (BG_HANDLER_NAME) ; 
mHandlerThread . start ( ) ; 

mBgHandler = new Handler (mHandlerThread. getLooper ()) ; 

L'oggetto mBgHandler è proprio quello che abbiamo passato al metodo addAccount o come ultimo 
parametro. Fatto questo, siamo sicuri che il metodo dicallback non verrà eseguito nel thread 
principale. Come abbiamo descritto in precedenza, unFuture<T> è un qualunque oggetto in grado di 
fornire, prima o poi, un riferimento a un oggetto t risultato di un task eseguito in modalità asincrona. 
Le prime istruzioni dovranno necessariamente essere queste: 

Bundle result = nuli; 
try { 

result = amf . getResult ( ) ; 

} catch (Exception e) { 
e . printStackTrace ( ) ; 

} 

Il metodo getResult o è infatti bloccante e rimarrà bloccato fino a quando non si renda disponibile 
un risultato di tipo Bundie o finché non accada una qualche eccezione. Per questo motivo dobbiamo 
succesivamente testare che il Bundie non sia nuli per poterlo considerare di esito positivo. Le 
successive istruzioni ci permettono di ottenere il nome dell'account e il relativo tipo daiBundie di 
ritorno per poi utilizzarle per la creazione dell'oggetto userModel nell'applicazione in modo analogo a 
quanto fatto in precedenza. In particolare abbiamo utilizzato le istruzioni 

final Account newAccount = 

AccountUtility . f indAccountByNameAndType (FirstAccessActivity . this , 
accountName, accountType) ; 
final UserModel userModel = 

UserModel . f romAccount (FirstAccessActivity .this, newAccount ) ; 
userModel . save (FirstAccessActivity . this ) ; 

La prima usa un metodo di utilità che abbiamo definito nella classe Accountutiiity, il quale ci 
permette semplicemente di cercare un account dato il nome e il tipo: 
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public static Account f indAccountByNameAndType (final Context context, 
final Strìng accountName, final String accountType) { 
final AccountManager accountManager = AccountManager . get (context ) ; 
Account [ ] accounts = accountManager . getAccountsByType (accountType) ; 
Account returnAccount = nuli; 
for (Account account : accounts) { 

if (account . name . equals (accountName) ) { 
returnAccount = account; 
break; 

} 

} 

return returnAccount; 

} 

Notiamo come l'unico modo sia quello di ottenere l'elenco di account per un dato tipo e quindi 
confrontarne il nome. L'istruzione successiva, che abbiamo implementato nella classe userModei, ci 
consente invece di crearne un'istanza utilizzando le informazioni all'interno dell'account. In 
precedenza abbiamo infatti visto come le informazioni relative a un utente siano contenute in altrettante 
proprietà dell'account creato: 

public static UserModei fromAccount ( final Context context, 

final Account account) { 
final AccountManager accountManager = AccountManager . get (context ) ; 
final String birthDateStr = accountManager . getUserData (account , 

BIRTHDATE_KEY) ; 

final String email = accountManager . getUserData (account, EMAIL_KEY) ; 
final String location = accountManager . getUserData (account, LOCATION_KEY) ; 
final UserModei userModei = new UserModei (Long. parseLong (birthDateStr) ) 

.withEmail (email) . withLocation (location) 

. withUsername (account . name) ; 
return userModei; 

} 

Questo metodo non fa altro che mappare le informazioni dell'account nelle corrispondenti dello 
userModei. Una volta creato l'oggetto userModei associato all'account appena creato, ne salviamo le 
informazioni attraverso il metodo save ( ) , come già fatto nella nostra prima implementazione. 



Cancellazione di un account 

Nel paragrafo precedente ci siamo occupati dell'integrazione della nostra interfaccia con 
l'operazione di login e creazione di un account. Un discorso analogo può essere fatto per 
l'operazione di logout e di cancellazione di un account. Questa volta si tratta del codice contenuto 
all'interno della classe MenuActivity in corrispondenza della selezione della relativa opzione di menu, 
che ora abbiamo inserito nel metodo doiogout ( ) : 

private void doLogout ( ) { 

final Strìng username = mUserModel . getUsername ( ) ; 
final Account accountToDelete = 

AccountUtility . f indAccountByNameAndType (this , username, 
AccountConst .UGHO_ACCOUNT_TYPE) ; 
mAccountManager . removeAccount (accountToDelete, 
new AccountManagerCallback<Boolean> ( ) { 

public void run (final AccountManagerFuture<Boolean> amf) { 

Thread waitResult = new ThreadO { 
public void run() { 

Boolean deleted = nuli; 
try { 

deleted = amf . getResult ( ) ; 
} catch (Exception e) { 
e .prìntStackTrace () ; 

} 

ìf (deleted != nuli && deleted) { 
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mUserModel . logout (MenuActivity . this) ; 
final Intent f irstAccessIntent = 

new Intent (MenuActivity . this , 

FirstAccessActivity . class) ; 
startActivity (f irstAccessIntent) ; 
finish () ; 

} 

}; 

waitResult . start ( ) ; 

} 

} , mBgHandler ) ; 

} 

Come possiamo vedere il meccanismo è lo stesso di prima, anche se questa volta il risultato è un 
Booiean che ne indica l'esito. In caso positivo abbiamo eseguito il logout o sull'oggetto userModei e 
poi siamo tornati alla schermata iniziale come nel caso precedente. 

L'ultima osservazione in relazione alla cancellazione dell'utente riguarda la presenza del seguente 

metodo della classe AbstractAccountAuthenticator 

public Bundle getAccountRemovalAllowed (AccountAuthenticatorResponse response, 
Account account) ; 

il quale non deve necessariamente essere implementato ma che rappresenta un punto di intervento 
qualora volessimo vincolare la cancellazione di un account a un'altra condizione oppure 
semplicemente eseguire delle operazioni di "pulizia" o rilascio di eventuali risorse. Nel nostro caso 
abbiamo semplicemente esplicitato il metodo richiamando l'equivalente della classe padre. 

Implementazione dell'AccountAuthenticator per la verifica di 

un account 

La procedura seguita fin qui riguarda la creazione di un nuovo account che, come potremo vedere, 
non si difièrenzierà molto da quella di verifica. Abbiamo già detto che un'applicazione potrebbe voler 
esplicitamente chiedere all'utente le proprie credenziali, che quindi andranno verificate. 

In questo caso l'operazione da implementare nel nostro UghoAuthenticator 6 

public Bundle conf irmCredentials (AccountAuthenticatorResponse response, 

Account account, Bundle optìons) throws NetworkErrorException 

dove abbiamo implementato la logica del diagramma nella Figura 13.12. 
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Figura 13.12 Flusso di verifica delle credenziali. 

Come il lettore può verificare consultando il codice allegato, la prima operazione è un controllo 
sulla presenza o meno dell'informazione della password all'interno delle opzioni passate come 
parametro al metodo conf irmCredentials ( ) . Nel caso in cui la password fosse presente, viene 
eseguito un accesso al server di autenticazione nel modo già latto in precedenza. Trattandosi di una 
gestione asincrona, il valore di ritorno del metodo dovrà quindi essere nuli e l'esito della verifica 
verrà gestito attraverso l'oggetto di tipo AccountAuthenticatorResponse. Nel caso in cui la 
password non fosse presente nelle opzioni, la procedura sarà simile a quella relativa alla creazione 
dell'account. Il seguente codice dovrebbe ormai essere completamente comprensibile in quanto molto 
simile a quanto già visto. Da notare solamente come l'esito dell'operazione avvenga attraverso un 
Bundle contenente un valore booleano con l'esito associato alla chiave 

AccountManager . KEY_BOOLEAN_RE SUITI 

public Bundle conf irmCredentials ( final AccountAuthenticatorResponse response, 
Account account, Bundle options) throws NetworkErrorException { 
ìf (options != nuli && options . containsKey (AccountManager . KEY_PASSWORD) ) { 

final String password = options . getString (AccountManager . KEY_PASSWORD) ; 
final String loginUrl = mContext . getResources ( ) 
. getString (R. string . login_url, account . name, 
MD5Utility .md5 (password) ) ; 
JsonOb jectRequest jsObjRequest = 

new JsonOb jectRequest (Request . Method . GET, loginUrl, nuli, new 
Response . Listener< JSONOb ject> ( ) { 

@Override 
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public void onResponse ( JSONOb ject jsonResponse) { 

UserModel userModel = UserModel . fromJson ( jsonResponse) ; 
final Bundle result = new Bundle (); 

result .putBoolean (AccountManager . KEY_BOOLEAN_RESULT, 

! userModel . hasError ( ) ) ; 
response . onResult (result) ; 

} 

}, new Response . ErrorListener ( ) { 
SOverride 

public void onErrorResponse (VolleyError error) { 
final Bundle result = new Bundle (); 

result .putBoolean (AccountManager . KEY_BOOLEAN_RESULT, false) ; 
result .putString (AccountManager . KEY_ERROR_MESSAGE, 

error . getMessage () ) ; 
response . onResult (result) ; 

} 

}) ; 

return nuli; 
} else { 

Intent checklntent = new Intent (mContext, UghoAuthActivity . class ) ; 
checklntent .putExtra (AccountManager 

. KEY_ACCOUNT_AUTHENTICATOR_RESPONSE , response) ; 
checklntent .putExtra (UghoAuthActivity . ACCOUNT_TYPE_P ARAM, 

AccountConst . UGHO_ACCOUNT_TYPE) ; 
checklntent .putExtra (UghoAuthActivity . TOKEN_TYPE_P ARAM, 

AccountConst . UGHO_TOKEN_TYPE) ; 
Bundle returnBundle = new Bundle (); 

returnBundle .putParcelable (AccountManager . KEY_INTENT, checklntent) ; 
return returnBundle; 

} 

} 

Questo è quindi il metodo della nostra classe ughoAuthenticator che viene invocato in 
corrispondenza di una richiesta di verifica di un account, la quale potrebbe essere richiesta 
dall'applicazione in diverse situazioni. Non è il nostro caso, ma pensiamo allo scenario in cui vi sono 
diversi account e si volesse passare da uno all'altro. Sebbene le informazioni siano già presenti, 
l'applicazione potrebbe formare l'utente a inserire nuovamente le credenziali e invocare il metodo 
descritto in precedenza: 

public AccountManagerFuture<Bundle> conf irmCredentials (Account account, 

Bundle options, Activity activity, AccountManagerCallback<Bundle> callback, 
Handler handler) 

Come esempio di utilizzo di questo metodo abbiamo aggiunto un'opzione di verifica insieme a 
quella di logout. Il corrispondente codice è molto simile al precedente: 

private void doVerifyO { 

final String username = mUserModel . getUsername ( ) ; 
final Account accountToConf irm = 

AccountUtility . f indAccountByNameAndType (this, username, 

AccountConst .UGHO_ACCOUNT_TYPE) ; 
mAccountManager . conf irmCredentials (accountToConf irm, nuli, this, 
new AccountManagerCallback<Bundle> ( ) { 
@Override 

public void run (AccountManagerFuture<Bundle> amf) { 
Bundle conf irmBundle = nuli; 
try { 

conf irmBundle = amf . getResult ( ) ; 
} catch (Exception e) { 
e.printStackTrace () ; 

} 

if (conf irmBundle != nuli) { 
Boolean confirmed = conf irmBundle 

.getBoolean (AccountManager . KEY_BOOLEAN_RESULT) ; 
if (confirmed != nuli && confirmed) { 

Toast .makeText (MenuActivity . this , "VERIFIED", 
Toast .LENGTH_SHORT) . show ( ) ; 
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} else { 

Toast .makeText (MenuAct ivity . this , "NOT VERIFIED", 
Toast .LENGTH_SHORT) . show ( ) ; 

} 

} else { 

Toast .makeText (MenuActìvity . this, "NOT VERIFIED", 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

} 

} , mBgHandler ) ; 

} 

In corrispondenza dell'esito della verifica visualizziamo quindi un Toast con un messaggio. 

Editing delle proprietà dell'account 

Nella sezione Accounts delle opzioni di configurazione abbiamo visto come sia possibile editare le 
eventuali opzioni di un account. Per semplificare il tutto, abbiamo deciso di gestire solamente l'URL 
del server di autenticazione, ma avremmo potuto inserire molte più informazioni Nel nostro caso 
abbiamo poi fatto in modo che l'URL per un account fosse condiviso con quello degli altri account 
dello stesso tipo. Per accedere, da un'applicazione, alla stessa attività di configurazione sarà 
sufficiente implementare, nella relativa specializzazione della classe UghoAuthenticator, la seguente 
operazione: 

public abstract Bundle editProperties (AccountAuthenticatorResponse response, 
String accountType) 

In questo caso si tratta di un'implementazione molto semplice che, in accordo a quanto fatto anche 
prima, dovrà ritornare un Bundie a che contiene l'intent per il lancio dell'attività di configurazione. 
Anche qui l'operazione potrà avvenire in modo sincrono o asincrono. Per riutilizzare la classe 
ughoAccountPreferenceActivity abbiamo deciso diusare la modalità sincrona e implementare il 
metodo come segue: 

public Bundle editProperties (AccountAuthenticatorResponse 
accountAuthenticatorResponse, String s) { 
Intent editlntent = new Intent (mContext , 

UghoAccountPreferenceActivity . class) ; 
Bundle returnBundle = new Bundle (); 

returnBundle .putParcelable (AccountManager . KEY_INTENT, editlntent) ; 
return returnBundle; 

} 

Il codice nell'activity dell'applicazione, che abbiamo inserito come opzione, è invece questo: 

private void doConfigO { 

mAccountManager . editProperties (AccountConst . UGHO_ACCOUNT_TYPE, 
this, nuli, mBgHandler) ; 

} 

È una versione molto semplificata, dove il risultato delle informazioni di configurazione non viene 
gestito in alcun modo. Lasciamo l'eventuale estensione al lettore. 

La gestione del token 

Come descritto più volte, il nostro sistema di autenticazione prevede la gestione di un token che 
l'applicazione può richiedere attraverso l'invocazione di imo dei metodi §etfcuthToken ( ) o 
getAuthTokenByFeatures o sull' AccountManager. In questo caso ilmetodo da implementare nello 
UghoAuthenticator ha la seguente firma: 

public Bundle getAuthToken (AccountAuthenticatorResponse response, 

Account account, String authTokenType, Bundle loginOptions ) 
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La logica che dovremo seguire è quella descritta nel diagramma delle attività nella Figura 13.13. 
Innanzitutto verifichiamo che il tipo di token richiesto sia supportato dall'implementazione 
dell' Authenticator. Nel caso non lo fosse ritorneremo il messaggio di errore corrispondente 
associandolo alla costante AccountManager .key_error_message nelBundie. Il passo successivo 
consiste nel controllo della presenza dell'informazione relativa alla password. In caso positivo si 
procede alla verifica attraverso l'invocazione del server di autenticazione. Se la verifica va a buon fine, 
ritorniamo le informazioni del token. Nel caso di esito negativo non faremo altro che inserire nel 
Bundie l'intent per la richiesta esplicita delle credenziali all'utente. La stessa operazione verrà fatta nel 
caso in cui la password non fosse presente. 

Sono operazioni molto simili a quella già viste per la verifica delle credenziali, per cui lasciamo al 
lettore la consultazione del codice allegato; ricordiamo solamente che richiedono un permesso del 
tipo: 

android . permission . USE_CREDENTIALS 

In questa fase andiamo invece a vedere come richiedere il valore del token attraverso il metodo 
getAuthToken o dell' AccountManager. Per ottenere tale valore si può infatti utilizzare un insieme di 
istuzioni simili a quelle già viste, con l'importante differenza che ora il valore del token ritornato viene 
messo nella cache. Eseguendo l'applicazione in debug oppure attraverso l'utilizzo di alcuni messaggi 
di log, è possibile vedere come il valore del token venga richiesto al corrispondente Authenticator 
solamente se non disponibile. Tutte le richieste successive vengono infatti esaudite immediatamente a 
meno che il valore del token non venga precedentemente reso invalido attraverso l'invocazione del 
metodo 

public void invalidateAuthToken (String accountType, String authToken) 

A tale proposito abbiamo aggiunto due opzioni di menu alla classe MainActivity. La prima ci 
permette di acquisire il token e la seconda di invalidarlo. 
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Il tipo di token è 
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Esiste la password ? 



NO 



SI 
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Accedi al server per la 
verifica delle credenziali 
in modo asincrono 



Impostiamo nel Bundle un 
messaggio di errore associato 
alla chiave 
KEY ERROR MESSAGE 



[notifica il risultato] 



M<"> JL 

T 



Inserisci nel Bundle le 
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verificato 



Ritorniamo il Bundle 



I 



Figura 13.13 Flusso di gestione del token. 

Abbiamo poi aggiunto un messaggio di log nel metodo getAuthToken ( ) della classe 
ughoAuthenticator per verificare se lo stesso viene invocato oppure no. Il lettore noterà come il 
metodo dell' Authenticator venga invocato solamente se il token non è disponibile. Tutte le altre volte 
il valore del token verrà visualizzato nel Toast senza invocare l' Authenticator in quanto il valore 
utilizzato è quello nella cache. Per forzare l'invocazione del token dal server dovremo quindi 
cancellare il token dalla cache con il metodo InvaiidateAuthToken ( ) descritto prima che il lettore 
potrà invocare attraverso l'opzione corrispondente. 

Per concludere l'aspetto relativo alla gestione del token ricordiamo solamente che la creazione del 
nostro Authenticator prevede anche l'implementazione dell'operazione 

public String getAuthTokenLabel (String authTokenType) 

che permette semplicemente di dare un'etichetta a ciascun tipo di token previsto dal particolare 
sistema di autenticazione. 



La gestione delle feature di un account 

Tra le possibili operazioni della classe AccountManager esiste anche quella che consente di 
interrogare il sistema sulla presenza o meno di un insieme di account di un particolare tipo che 
soddisfino alcune funzionalità associate a quelle che abbiamo chiamato feature. Il metodo per farlo è 
descritto dall'operazione 

public AccountManagerFuture<Account [ ] > getAccountsByTypeAndFeatures (String type, 
String [] features, AccountManagerCallback<Account [ ] > callback, 
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Handler handler) 

la cui firma ci è ormai abbastanza familiare. Il filtro degli account di un particolare tipo viene gestito 
in modo automatico dal sistema, che per la parte relativa alle feature si appoggia all'implementazione 
dell' Authenticator, il quale dovrà in qualche modo implementare la seguente operazione: 

public Bundle hasFeatures (AocountAuthenticatorResponse response, 

Account account , String [ ] features) throws NetworkErrorException 

In questo metodo si dovrà descrivere il criterio secondo cui un account passato soddisfa o meno i 
criteri contenuti nell'array features. La modalità con cui ritornare il risultato di questa verifica è ormai 
il solito e prevede la valorizzazione di alcune proprietà di un Bundie. Nella nostra implementazione 
ritorniamo il valore false associato alla chiave AccountManager .key_boolean_result per indicare 
che qualunque sia la particolare feature i nostri account non la soddisferanno. Ricordiamo che le 
feature sono delle strìng che dipendono dal meccanismo specifico di autenticazione per cui lasciamo 
al lettore l'eventuale personalizzazione di questo aspetto: 

@Override 

public Bundle hasFeatures (AccountAuthenticatorResponse respone, 

Account account, Stringi] strings) throws NetworkErrorException { 
final Bundle f eatureBundle = new Bundle (); : 

f eatureBundle . putBoolean (AccountManager . KEY_BOOLEAN_RESULT, false) ; 
return f eatureBundle; 

} 

Nel codice precedente abbiamo evidenziato la parte di definizione del risultato negativo. 

Update delle credenziali 

L'ultimo aspetto che le diverse specializzazioni della classe Abstract Account Authenticator 
devono necessariamente implementare è la funzione di aggiornamento delle credenziali di un account, 
ovvero dell'operazione che è possibile eseguire attraverso questo metodo della classe 

AccountManager: 

public AccountManagerFuture<Bundle> updateCredentials (Account account, 
String authTokenType, Bundle options, Activity activity, 
AccountManagerCallback<Bundle> callback, Handler handler) 

Un'operazione di questo tipo corrisponde semplicemente alla richiesta esplicita all'utente delle 
credenziali, cosa che è possibile fare implementando la seguente operazione dell' Authenticator 
come già visto in precedenza: 

public Bundle updateCredentials (AccountAuthenticatorResponse response, 
Account account, String s, Bundle bundle) 
throws NetworkErrorException { 
Intent checklntent = new Intent (mContext, UghoAuthActivity . class ) ; 
checklntent .putExtra (AccountManager . KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, 
response) ; 

checklntent .putExtra (UghoAuthActivity . USERNAME_P ARAM, account . name) ; 
checklntent .putExtra (UghoAuthActivity . TOKEN_TYPE_P ARAM, 

AccountConst . UGHO_TOKEN_TYPE) ; 
checklntent .putExtra (UghoAuthActivity . CONFI RM_CREDENTIAL_P ARAM, false) ; 
final Bundle resultBundle = new Bundle (); 

re sult Bundle .putParcelable (AccountManager . KEY_INTENT, checklntent ) ; 
return resultBundle; 

} 

Come possiamo comprendere dal codice precedente, si tratta del lancio dell'attività di richiesta 
delle credenziali passando le informazioni relativa al solo username e quindi costringendo l'utente 
all'inserimento della password. Questo comporterà una successiva verifica sul server di autenticazione 
e il salvataggio delle nuove credenziali 
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Integrazione del login di Facebook 

Come abbiamo accennato all'inizio di questo capitolo l'integrazione dei sistemi di autenticazione 
con quelli dei più tàmosi social network è uno degli aspetti più importanti della maggior parte delle 
app Reazioni mobili e quindi anche diAndroid. Per questo motivo in questo paragrafo ci occuperemo 
dell'integrazione del nostro sistema di autenticazione con quello del social network più famoso, 
ovvero Facebook. In questo caso il nostro lavoro è semplificato dalla presenza di un SDK che il 
social network mette a disposizione all'indirizzo 

https : //developers . facebook . coni/ resources/f acebook-android-sdk-3 .0.2. zip. 

Come possiamo notare dal nome del file, si tratta dell' SDK giunto ormai alla versione 3.0, per 
scaricare il quale è necessario avere un account ed essere loggati. E un archivio che contiene l'SDK 
di Facebook per Andro id insieme a un'applicazione che è possibile installare oppure no. Se presente, 
le API di Facebook utilizzeranno tale applicazione allo stesso modo con cui i servizi di Google 
utilizzano l'applicazione per i Play Services. Una volta aperto l'archivio in ima cartella di supporto, si 
ottiene la struttura nella Figura 13.14. 

Come possiamo vedere esiste una cartella che si chiama facebook, che andiamo a copiare nella 
cartella che abbiamo già usato per altre librerie come quella di ActioBarSherlock e Volley, ovvero la 
cartella /libraries, ottenendo la struttura nella Figura 13.15. 

Anche qui abbiamo bisogno di creare un file per Gradle, che sarà molto simile a quello che 
abbiamo utilizzato per Volley, anch'esso un progetto nato per eclipse. Creiamo il seguente file di nome 
build . gradle e inseriamolo nella cartella facebook: 



„ bin 

| ' CONTRIBUTINC.mdown 

docs 

M facebook 

a nbs 

LICENSE.txt 
NOTICE.txt 
README.mdown 
samples 

Figura 13.14 Struttura a directory dell'archivio scaricato. 
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Figura 13.15 Abbiamo importato il progetto facebook nel nostro progetto UGHO. 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/maven2' } 

} 

dependenoies { 

classpath 1 com. andrò id . tools . build : gradle : 0 . 5 . + ' 

} 

} 

apply plugin: ' android-library ' 

dependencies { 

compile ' com. android. support : support-v4 : 13 . 0 . + ' 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdkVersion 7 
targetSdkVersion 16 
} 

sourceSets { 
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main { 

manif est . srcFile ' AndroidManif est . xml ' 

java.sroDirs = ['src'] 

resouroes . srcDirs = ['src'] 

aidl . srcDirs = ['src'] 

renderscript . srcDirs = ['src'] 

res. srcDirs = [ ' res ' ] 

assets . srcDirs = ['assets'] 

} 

} 

} 

Inoltre non dimentichiamo di modificare il file di configurazione settings . gradie aggiungendo il 
riferimento alla libreria appena copiata. Il contenuto di questo file sarà il seguente: 

include ':UGHO' , ' : libraries : ActionBarSherlock ' , ': libraries : volley ' , 
' : libraries : f acebook ' 

L'ultimo passo consiste nelT importare la libreria nel file di Gradle del nostro progetto UGHO, 
ovvero nel file buiid.gradie, che diventa 

buildscript { 

repositories { 

maven { uri 'http://repol.maven.org/niaven2' } 

} 

dependencies { 

classpath ' com. andrò id . tools . build : gradle : 0 . 5 . + ' 

} 

} 

apply plugin: 'android' 

dependencies { 

compile project ( ' : libraries : ActionBarSherlock ' ) 
compile project (' : libraries : volley ' ) 
compile project ( ' : libraries : f acebook ' ) 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdkVersion 8 
targetSdkVersion 16 

} 

} 

A questo punto siamo pronti all'integrazione, e tutte le classi e le risorse dovrebbero essere visibili 
all'interno del nostro progetto. Prima di scrivere del codice dobbiamo però eseguire alcune 
operazioni di configurazione nell'amministrazione diFacebook. 

Creazione di un'applicazione Facebook 

Quando si utilizza l'SDK diFacebook è necessario lare affidamento a quella che viene definita 
Application e che può essere creata attraverso gli strumenti messi a disposizione dalla sezione 
Developer del social network. Questa operazione si rende necessaria solo nel caso in cui 
l'applicazione non esistesse già, come nel nostro caso. E sufficiente andare nella Dashboard di 
Facebook nella sezione developers all'indirizzo https : //deveiopers . facebook . com/apps/ (il quale 
verrà contestualizzato al particolare utente). Qui è possibile accedere all'elenco delle applicazioni 
create o per le quali si ha un ruolo di collaboratore. Nel nostro caso creiamo una nuova applicazione 
attraverso l'opzione nella Figura 13.16, che si trova in alto a destra. 



566 



/ Edit App 



+ Create New App 



Figura 13.16 Pulsante per la creazione di una nuova applicazione Facebook. 

Selezionando il pulsante per la creazione dell'applicazione si aprirà ima finestra con la richiesta 
delle informazioni (Figura 13.17). 



Create New App 



App Name UCHO 
App Namespace ughoapp 
App Category Lifestyle 



Valid 
Avallatile 



*$1 I Choose a sub-category J 



Web Hosting fi (j Yes, I would like free web hosting provided by Heroku (Learn More) 



By proceeding, you agree to the Facebook Platform policies 



Continue 



Cancel 



Figura 13.17 Informazioni relative all'applicazione da creare. 

Da notare come il campo del nome dell'applicazione non possa contenere nomi per i quali esistono 
dei copyright, per cui un nome come my_f aoebook_app non sarebbe accettato. Il secondo campo ci 
permette di specificare un namespace per la gestione di OpenGraph. 

NOTA 

OpenGraph è un insieme di API offerte da Facebook che permettono di ottenere informazioni di 
carattere generale sui vari utenti del social network. È uno strumento molto potente che comunque 
non tratteremo e per il quale si rimanda alla documentazione ufficiale all'indirizzo 

https : //developers . facebook. corti/ docs/ref erence/api/. 

I successivi campi sono relativi alla categoria dell'applicazione che vogliamo creare oppure alla 
decisione se utilizzare gratuitamente i servizi di hosting di Heroku (https : / /www . heroku . com/). 

NOTA 

Heroku è uno dei principali provider per l'hosting di applicazioni che utilizzano diverse tecnologie. 
Secondo la politica di pricing attuale, consente la creazione di applicazioni gratuite per bassi livelli 
di traffico. 

Selezionando il pulsante Continue ci viene richiesto l'inserimento di un captcha che, se aggiunto 
correttamente, porta a ima pagina riassuntiva con tutte le informazioni dell'applicazione appena creata 
(che abbiamo in parte offiiscato), tra cui quelle nella Figura 13.18. 




UCHO 



232 



App ID: 200 

App Secret: 98d4|BK^BMÌÌÈ096eee5b5 (reset) 
& This app is in Sandbox Mode (Only visible to Admins, Developers and Testers) 
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Figura 13.18 Le informazioni che caratterizzano in modo univoco la nostra applicazione. 



Il passo successivo consiste nella creazione delle informazioni relative all'applicazione Andro id che 
utilizzerà i servizi di Facebook. In particolare in questa fase inseriremo le informazioni relative alle 
hash key per i vari certificati che si andranno a utilizzare per l'applicazione. Questo perché ogni 
particolare sistema dispone della propria modalità di firma da cui Facebook vuole astrarsi In ima 
situazione normale si dovranno registrare le hash key usando il tool keytool sia per il certificato di 
sviluppo sia per quello di produzione. Nel nostro esempio registriamo l'hashkey solamente per il 
certificato di debug, che sappiamo essere nella cartella .androìd dell'utente corrente. Il procedimento 
per la creazione e registrazione dell'hashkey per il certificato di produzione è esattamente lo stesso, 
solo che fa riferimento, appunto, a unkeystore diverso. Andiamo in questa cartella ed eseguiamo il 
comando 

keytool -exportcert -alias <KEYSTORE ALIAS KEY> -keystore <KEYSTORE PATH> 
I openssl shal -binary | openssl base64 

che nel caso specifico diventa 

keytool -exportcert -alias android -keystore debug . keystore 
I openssl shal -binary | openssl base64 

ottenendo il seguente output (anche questa volta offuscato in parte con l'inserimento di qualche X): 

massimocarli$ keytool -exportcert -alias android -keystore debug . keystore I openssl shal 

-binary | openssl base64 

Enter keystore password: android 

PXz2XXXXnw8MYXXXXXGrqcPeXXX= 

Notiamo come al termine del messaggio di output vi sia l'hash key richiesta, che andiamo a inserire 
nel forai relativo all' app Reazione Android, come possiamo vedere dalla Figura 13.19. 



Website with Facebook Login 


Log in to my website using Facebook. 


App on Facebook 


Use my app inside Facebook.com. 


Mobile Web 


Bookmark my web app on Facebook mobile. 


Native iOS App 


Publish from my iOS app to Facebook. 


Native Android App 






Package Name: [?1 


uk. co. massi mocarli. android. ug ho 








Class Name: 
Key Hashes: 
Facebook Login: 
Deep Linking: 


uk.co. massi mocarli. android. ugho.activity.TouchSplashActivity 










% Enabled Disabled 
Enabled 0 Disabled 


1 * 
<y Page Tab 


Build a custom tab for Facebook Pages. 








1 Save Changes 1 





Figura 13.19 Form per l'inserimento delle informazioni relative all'applicazione Android. 



Vediamo che è stata selezionata l'opzione relativa al Facebook Login in quanto si tratta di una 
funzionalità che vogliamo effettivamente attivare. Fatto questo selezioniamo il pulsante Save Changes 
per rendere il tutto effettivo dopo un tempo di propagazione di qualche minuto. Nella stessa 
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schermata abbiamo inserito anche le informazioni relative al package dell' applicazione oltre che il 
nome della classe dell' activity che verrà lanciata a seguito del login (completa di package). 

Le informazioni appena ottenute sono necessarie per la configurazione della nostra applicazione. 
Per farlo abbiamo creato un file di nome f acebook . xml con le informazioni necessarie, che abbiamo 
inserito tra le risorse di tipo /values/. In particolare il nostro file conterrà solamente la definizione 
dell'identificativo dell'applicazione: 

<! — Risorse Facebook — > 

<string name="app_id">3XX90 6XXX4 3XXX5</string> 

Dopo aver controllato la presenza del permesso INTERNET relativo alla connessione internet 
dobbiamo aggiungere la seguente definizione nel file AndroidManif est . xml come figlia dell'elemento 

<application/>: 

<meta-data android : name="com . facebook . sdk . Applioationld" 
android: value=" @ string /app_id" / > 

L'ultimo passo della configurazione consiste nella definizione dell'attività che verrà poi usata per 
eseguire il login con i dati di Facebook: 

<! — Integrazione Facebook — > 

<activity android: name="com. facebook . LoginActivity " /> 

Quanto fatto riguarda però il normale login, mentre nella nostra applicazione avremo bisogno di 
alcune informazioni personali dell' utente per le quali dobbiamo richiedere in modo esplicito il 
permesso. A tale proposito torniamo nell'amministrazione di Facebook e precisamente nella sezione 
relativa ai permessi, come evidenziato nella Figura 13.20. 
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Figura 13.20 Sezione dei permessi nel menu di configurazione. 

In questa sezione è molto importante aggiungere i permessi elencati nella sezione User & Friend 
Permìssions. In particolare stiamo dicendo che la nostra applicazione necessita dei permessi per 
l'acquisizione delle informazioni relative all'e-mail, alla location e soprattutto alla data di nascita degli 
utenti Una volta salvate le modifiche siamo quindi pronti all'integrazione del pulsante di login 
nell'applicazione. 

Codice di integrazione del login di Facebook 

Dopo aver configurato l'applicazione Facebook associata alla nostra applicazione è giunto il 
momento di scrivere un po' di codice. In questa fase è importante sottolineare come tutte le 
operazioni di Facebook che richiedono autenticazione debbano essere ottenute attraverso un'istanza 
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della classe com.facebook.session. È un oggetto con un proprio ciclo di vita che dovrà in qualche 
modo essere legato al ciclo di vita dell'applicazione, o meglio dei suoi componenti, che sono fragment 
e activity. Per questo motivo FSDK ci offre la classe uiLifecycieHeiper per la gestione di tutte le 
operazioni di autenticazione e di gestione del ciclo di vita della sessione, di cui otterremo notifica 
attraverso l'implementazione delle operazioni dell'interfaccia session.statuscaiiback. Si tratta 
dell'interfaccia che i nostri fragment o le nostre activity dovranno implementare per ricevere notifica 
dello stato della sessione che poi utilizzeremo. 

Il primo passo verso la gestione del logjn (e del logout) consiste nel selezionare il tipico pulsante di 
Facebook, il quale è messo a disposizione dall'SDK attraverso la classe LoginButton. Si tratta di ima 
specializzazione del classico Button diAndroid ma con un forte legame con l'oggetto 
uiLif ecycieHeiper, con il quale è possibile interagire attraverso l'interfaccia di callback. Per fare 
quanto descritto andiamo nel layout di registrazione (il nostro file activity_social_login . xml) e 
aggiungiamo la seguente definizione relativa appunto al pulsante di login per Facebook: 

<com . facebook . widget . LoginButton 
android: id=" @+id/login_button" 
android: layout_width="wrap_content " 
android: layout_height="wrap_content " 
android: layout_gravity="center_horizontal " 
android: layout_marginTop=" 30dp" 
android: layout_marginBottom="30dp" /> 

È possibile che l'utilizzo di questo elemento porti a degli errori dovuti alla mancanza di ima qualche 
risorsa di tipo String. 

NOTA 

È inoltre probabile che la preview di Android Studio dia qualche errore, di cui non dobbiamo 
preoccuparci. Testeremo poi l'applicazione su un dispositivo reale che farà fede. 

Per questo motivo è bene aggiungere la seguente definizione tra le risorse di tipo String, che noi 
abbiamo raggruppato nel file facebook . xml! 

<string name="get_started">To get started, log in using Facebook</string> 

A questo punto andiamo all'attività digestione del login e integriamo l'utilizzo dell'oggetto di tipo 
sessìon. Creiamo quindi, nella classe ughoAuthActivity digestione del login, un' implementazione 
dell'interfaccia session.statuscaiiback nel seguente modo: 

private final Session . StatusCallback mFacebookCallback = 
new Session . StatusCallback ( ) { 

SOverride 

public void cali (Session session, SessionState state, 
Exception exception) { 
// Implementazione 

} 

}; 

Si tratta di un'implementazione al momento vuota che utilizziamo per la definizione dell'oggetto di 

tipo UiLif ecycleHelper che Creeremo nel metodo onCreate o : 
private UiLif ecycleHelper mLif ecycleHelper ; 

HOverride 

public void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 

mLif ecycleHelper = new UiLif ecycleHelper (getActivity () , 

mFacebookCallback) ; 
mLif ecycleHelper . onCreate (savedlnstanceState) ; 
List<String> requestedPermission = 

Arrays . asList ( "email" , "user_location" , "user_birthday" ) ; 
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LoginButton facebookLoginButton = (LoginButton) 

f indViewBy Id (R . id . f acebook_login_button) ; 
facebookLoginButton. setReadPermissions (requestedPermission) ; 

} 

Insieme alla creazione dell'oggetto UìLif ecycleHelper SI ha la notifica delle informazioni relative 
all'eventuale Bundie con lo stato da ricostruire. E il primo metodo che incontriamo per ilbinding tra il 
ciclo di vita della sessione e quello della nostra activity o del nostro fragment. Le istruzioni successive 
sono di fondamentale importanza in quanto ci permettono di definire quali sono i permessi che l'utente 
che esegue il logjn attraverso la nostra applicazione dovrà accettare. Nel nostro caso abbiamo 
utilizzato il metodo setReadPermissiono per informare l'utente che inserendo le sue credendziali 
consentirà all'applicazione il reperimento delle informazioni corrispondenti 

NOTA 

È importante sottolineare come qualora il pulsante fosse utilizzato all'interno di un fragment si 
renderebbe necessaria l'invocazione del metodo setFragmento per passare il riferimento al fragment 
stesso al pulsante di login. Questo per informare il framework che il ciclo di vita di riferimento sarà 
quello di un fragment e non quello di un'activity. 

Insieme ai metodi precedenti abbiamo comunque bisogno di legare il ciclo di vita della sessione a 
quello dell' activity (o fragment), per cui dobbiamo implementare anche queste operazioni; 

@Override 

public void onResumet) { 
super . onResume ( ) ; 
mLif ecycleHelper . onResume ( ) ; 

} 

@Override 

public void onPause () { 
super . onPause ( ) ; 
mLif ecycleHelper . onPause () ; 

} 

HOverride 

public void onDestroyO { 
super . onDestroy ( ) ; 
mLif ecycleHelper . onDestroy ( ) ; 

} 

HOverride 

public void onSavelnstanceState (Bundle outState) { 
super . onSavelnstanceState (outState) ; 
mLif ecycleHelper . onSavelnstanceState (outState) ; 

} 

gOverride 

public void onActivityResult (int requestCode, int resultCode, Intent data) { 
super . onActivityResult (requestCode, resultCode, data) ; 
mLif ecycleHelper . onActivityResult ( requestCode, resultCode, data) ; 

} 

Il layout della nostra schermata di login sarà ora quella nella Figura 1 3 .2 1 . Il pulsante di login potrà 
essere posizionato ovunque in base alle proprie esigenze. 

Premendo il pulsante otterremo la visualizzazione la schermata di richiesta di login nella Figura 
13.22. 

A questo punto verifichiamo cosa succede al nostro metodo di callback nel caso in cui l'utente 
chiudesse questa finestra selezionando l'icona di chiusura in alto a sinistra oppure premendo il 
pulsante Back del dispositivo. 

Nel momento di pressione del pulsante di login viene invocato il metodo di callback cali o, a cui 
viene passato lo stato caratterizzato dal valore sessionstate.oPENiNG, che ci informa che è iniziato il 
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processo di apertura della sessione. 




Username: 




Figura 13.21 Schermata di login con il pulsante di Facebook. 
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Figura 13.22 Schermata di login di Facebook. 

Nel caso di pressione del pulsante Back o di chiusura della finestra di login, il metodo di callback 
viene invocato con un valore per lo stato dato dalla costante sessionstate . closed_login_failed. 
Andando a esaminare il tipo dell'eccezione sollevata otterremo 

com. facebook. FacebookOperationCanceledException, che in effetti indica la Cancellazione 

dell'operazione di login. Un altro caso è quello in cui sbagliamo le credenziali di accesso ottenendo 
quanto mostrato nella Figura 13.23, ovvero il messaggio di errore direttamente nell'interfaccia senza 
alcuna invocazione del metodo di callback. 
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Non abbiamo riconosciuto il tuo indirizzo e-mail o 
numero telefonico. 

Hai bisogno di un account 7 

La password ti verrà mostrata qui sotto in formato di testo per 
facilitare l'immissione del testo (l'accesso sarà comunque 
protetto) 



Scarica Facebook per Android e naviga 
più velocemente. 



Figura 13.23 Errore nel login. 

Vediamo allora che cosa succede nel caso in cui il login abbia successo. La prima volta che l'utente 
esegue il login viene visualizzata una schermata che informa l'utente di quello che sta per fare, 
chiedendo il permesso di accedere alle relative informazioni. Nel nostro caso si ottiene la schermata 
nella Figura 13.24. 
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UGHO would like to access your public 
profile, friend list, email address. birthday 
and current city. 



Figura 13.24 Richiesta del permesso di accesso ai propri dati. 

A questo punto l'utente può accettare o rifiutare. In caso di rifiuto l'effètto è lo stesso dei casi 
precedenti, ovvero il tutto viene interpretato come un annullamento nel processo di login. 11 nostro 
oggetto dicallback riceve quindi la notifica con imo stato sessionstate . closed_login_failed. 

fi caso più interessante si ha quando il login ha successo e la richiesta di permesso è confermata. In 
questo caso lo status corrisponde al valore sessionstate.oPENED, la schermata di login si chiude e il 
pulsante modifica la propria etichetta e la funzionalità in quella di logout, come vediamo nella Figura 
13.25. 
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Username: 



Password: 



Figura 13.25 II pulsante è diventato di logout. 

Quando la sessione è in questo stato possiamo finalmente accedere alle altre informazioni, come 
vedremo nel prossimo paragrafo. A questo punto la pressione del pulsante di logout porterà 
l'applicazione, dopo una richiesta di conferma (Figura 13.26), allo stato iniziale, con il pulsante che 
ritornerà ad avere l'etichetta per il logjn Durante il processo di logout, il metodo di callback riceve 
una notifica associata allo stato sessionstate . closed. 
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Log Out 



Username: 




Figura 13.26 Richiesta di conferma per l'operazione di logout. 



Otteniamo le informazioni dell'utente 

A questo punto l'utente è loggato ma non basta: abbiamo bisogno delle informazioni per le quali 
abbiamo richiesto le autorizzazioni, ovvero e-mail, location e data di nascita. Per farlo dobbiamo 
utilizzare il meccanismo che Facebook ci mette a disposizione, il quale è basato sugli oggetti di tipo 

• Request 

• Response 

• GraphUser 

Una Request è un oggetto che incapsula le informazioni relative a una richiesta, la quale può 
necessitare delle autorizzazioni oppure no. Nel primo caso una request ha necessariamente bisogno di 
una sessione ottenuta da un'operazione di login con i permessi richiesti. Nel caso in cui per la request 
non occorrano autorizzazioni, la sessione non sarà obbligatoria. Un aspetto interessante dell'utilizzo 
delle Request riguarda il fatto che permettono di aggiornare il token in caso di successo. Una 
Response è un oggetto che incapsula l'esito di una richiesta. Infine un oggetto di tipo Graphuser 
incapsula tutte le informazioni disponibili relativamente a un particolare utente. Le API di Facebook ci 
mettono a disposizione diversi tipi di Request per i quali rimandiamo alla documentazione ufficiale. 
Nel nostro caso abbiamo implementato il seguente metodo, che ci ha permesso di ottenere le 
informazioni relative all'utente loggato, ovvero quelle necessarie alla creazione dell'oggetto 
userModei. È importante sottolineare come il nostro codice sia stato incapsulato all'interno di un 
metodo di utilità di nome fetchuserData o , invocato dal metodo dicallback dell'interfaccia 
session . statusCaiiback nel caso in cui il login fosse avvenuto con successo e quindi lo stato della 
sessione fosse corrispondente al valore sessionstate.oPENED. 

private final Session . StatusCallback mFacebookCallback = 
new Session . StatusCallback ( ) { 

@Override 

public void cali (Session session, SessionState state, 
Exception exception) { 
ìf (state == SessionState.OPENED) { 
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fetchUserData (session) ; 

} 

} 

}; 

L'informazione sulla location non è sempre disponibile, per cui abbiamo aggiunto un controllo nel 
metodo toJson o in modo da non generare una NuiiPointerException: 

private void fetchUserData (final Session session) { 

com. facebook.Request request = com. facebook . Request . newMeRequest (session, 
new com. facebook . Request . GraphUserCallback ( ) { 
SOverride 

public void onCompleted (GraphUser user, com . facebook . Response response) { 
ìf (session == Session . getActiveSession () ) { 
if (user != nuli) { 

final String username = user . getUsername ( ) ; 

final GraphLocation location = user.getLocation() ; 

final String birthDateStr = user . getBirthday ( ) ; 

final String email = (String) user . getProperty ( "email" ) ; 

final SimpleDateFormat formatter = 

new SimpleDateFormat ( "MM/dd/yyyy" ) ; 
Date birthDate = new DateO; 
try { 

birthDate = formatter .parse (birthDateStr ) ; 
} catch (ParseException e) { 
e .printStackTrace ( ) ; 

} 

final UserModel tmpUser = UserModel 

.create (birthDate . getTime ( ) ) . withEmail (email) 
. withUsername (username) ; 

if (location != nuli) { 

tmpUser . withLocation (location . getCity ( ) ) ; 

} 

final Bundle initBundle = tmpUser . toBundle () ; 
final Account account = new Account (username, 

AccountConst . UGHO_ACCOUNT_TYPE) ; 
final boolean created = mAccountManager 

. addAccountExplìcitly (account, "password", 
initBundle) ; 
final Intent resultlntent = new Intento ; 
resultlntent .putExtra (AccountManager . KEY_ACCOUNT_NAME, 
username) ; 

resultlntent .putExtra (AccountManager . KEY_ACCOUNT_TYPE, 

AccountConst .UGHO_ACCOUNT_TYPE) ; 
resultlntent .putExtra (AccountManager . KEY_BOOLEAN_RESULT, true) ; 
set Account Authenticat or Re sult ( resultlntent . getExtras ( ) ) ; 
setResult (RESULT_OK, resultlntent) ; 
finish ( ) ; 

} 

} 

if (response . getError () != nuli) { 
// Gestione dell'errore 

} 

} 

}) ; 

request . executeAsync ( ) ; 

} 

Come possiamo vedere nel codice evidenziato, la Request, di cui abbiamo esplicitato il package in 
quanto in conflitto con l'analoga classe di Volley, ci ritorna un oggetto di tipo Graphuser che contiene 
tutte le informazioni che abbiamo richiesto e di cui abbiamo chiesto il consenso. Da queste abbiamo 
poi creato l'account, da cui la notifica nel modo ormai usuale. 



Sincronizzazione 

In questo capitolo abbiamo introdotto dei concetti molto importanti che riguardano la definizione di 
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un account e la relazione con un insieme di contatti basati sul contatto stesso. Come accennato, sono 
principi abbastanza ostici, perlopiù non molto documentati da Google, che utilizzeremo per la 
realizzazione di quello che prende il nome di feyncAdapter. Si tratta di un componente che, 
appoggiandosi a un particolare account, permette di gestire in modo automatico le operazioni di 
sincronizzazione tra le informazioni presenti in un content provider e quelle accessibili attraverso la 
rete. E un'operazione legata a un particolare account per cui viene spesso utilizzata spesso per la 
sincronizzazione dei contatti. In questo paragrafo realizzeremo invece un syncAdapter per la 
sincronizzazione degli inserimenti, ovvero quell'operazione che abbiamo eseguito con l'inserimento di 
un dato e che abbiamo incapsulato all'interno del metodo syncLocalData ( ) della classe 
Synchron izer. Ci concentreremo sulla configurazione del componente in relazione alla gestione degli 
account e dell'accesso alla rete. Vediamo i passi, molto semplici, che seguiremo. 

1 . Abilitazione degli account alla sincronizzazione. 

2. Dichiarazione del SyncAdapter attraverso i file XML di configurazione. 

3. Implementazione del SyncAdapter e delle funzionalità di accesso al relativo content provider. 

4. Definizione del servizio per l'esportazione del SyncAdapter. 



Abilitazione della sincronizzazione 

All'inizio di questo capitolo abbiamo creato degli account che il lettore più attento avrà notato non 
essere abilitati alla sincronizzazione, come possiamo vedere dalla Figura 13.27. 
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Figura 13.27 La sincronizzazione inizialmente non è attiva. 

Il motivo di tutto questo è che, al momento della creazione dell' accont, lo stesso non è stato 
abilitato alla sincronizzazione attraverso il syncAdapter. Per eseguire questa abilitazione dobbiamo 
quindi ritornare al codice responsabile della creazione dell'account che abbiamo inserito nella classe 
UghoAuthActivity e che ora ci accingiamo a modificare. Per la precisione abbiamo creato l'account, 
dopo una verifica latta attraverso l'accesso al server di autenticazione, tramite l'invocazione del 
metodo addAccountExpiicitiyo dell' AccountManager all'interno delmetodo doLogino. Questo è 
il luogo idoneo in cui abilitare l'account attraverso il seguente metodo statico della classe 

ContentResolver: 

public static void setSyncAutomatically (Account account, String authority, boolean sync) 

Esso consente di abilitare l'account passato come parametro alla sincronizzazione delle 
informazioni relative al content provider di cui si specifica l'authority. Il parametro sync permette di 
abilitare o meno tale sincronizzazione, che avverrà in corrispondenza di un evento lanciato dal sistema. 
Nel caso in cui l'account venisse utilizzato per la sincronizzazione dei nostri dati, l'istruzione da 
eseguire sarà 

ContentResolver . setSyncAutomatically (account, UghoDB .AUTHORITY, true) ; 

dove la costante ughoDB. authority identifica proprio l'authority voluta. Un aspetto molto 
importante della sincronizzazione riguarda la sua frequenza. Per informazioni che variano molto 
lentamente non ha senso avere frequenze di aggiornamento elevate a differenza di altre, come per 
esempio la mail, che necessitano di frequenze più alte. In linea di principio è comunque bene non 
esagerare, al fine di preservare il più possibile le risorse critiche come la batteria. A tale scopo esiste il 
seguente metodo sempre della classe ContentResolver 

public static void addPeriodicSync (Account account, String authority, 
Bundle extras, long pollFrequency ) 

dove il principale parametro di interesse è pollFrequency, il quale permette di impostare la 
frequenza di sincronizzazione specificando un valore in secondi. 

Una volta abilitata la gestione della sincronizzazione per gli account relativi al nostro sistema di 
autenticazione, la parte interessata del metodo doLogin ( ) della classe tghoAutnActivity del nostro 
progetto diventa: 

final boolean created = mAccountManager . addAccountExplicitly (account, 

password, initBundle) ; 
if (created) { 

ContentResolver . setSyncAutomatically (account, UghoDB .AUTHORITY, true) ; 
ContentResolver .addPeriodicSync (account, UghoDB . AUTHORITY, new Bundle (), 
AccountConst . SYNC_UPDATE) ; 

} 

Si tratta del primo passo verso la gestione della sincronizzazione dei contatti attraverso 

SyncAdapter. 

Dichiarazione del SyncAdapter 

In questa fase dobbiamo descrivere il particolare syncAdapter al sistema, cosa che avviene 
attraverso la compilazione di un documento XML che abbiamo descritto all'interno del file 
ugho_sync_adapter . xml nella cartella res/xml delle risorse XML: 

<?xml version=" 1 . 0 " encoding="utf-8" ?> 

<sync-adapter xmlns : android="http : / /schemas . android . corri/ apk/res/ android" 
android : account Type="uk . co . massimocarli .android . ugho . account " 
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androidi: allowParallelSyncs=" false" 

androidi: contentAuthority="uk . co . massimocarli . android. ugno" 
android: isAlwaysSyncable="true" 
android : supportsUploading=" false " 
android:userVisible="true" /> 

E un documento molto importante che definisce, attraverso l'attributo android: contentAuthority, 

l'authority associata al content provider che lo stesso syncAdapter intende aggiornare. Le 

informazioni relative al tipo di account vengono invece specificate attraverso l'attributo 

android :accountType; ci permetteranno di far siche le attività di sincronizzazione descritte da questo 

particolare syncAdapter riguardino l'account relativo al tipo specificato e permettano l'aggiornamento 

delle informazioni del content provider dei nostri input. L'ultimo attributo, 

android: supportsUploading (uno dei meno documentati), consente invece di specificare se le 

informazioni sincronizzate possono essere editate nel dispositivo e quindi inviate (upload) al server 

per la modifica. Si tratta di un'informazione che nel nostro caso non assume alcuna importanza, a 

differenza di quello che succede nel caso di sincronizzazione del content provider dei contatti 

Implementazione del SyncAdapter 

Da quanto visto finora abbiamo capito che un syncAdapter è un oggetto che viene attivato a 
seguito di un evento di scheduling da parte del sistema e si preoccupa di sincronizzare le informazioni 
di una base dati remota con quelle presenti in un content provider. Un aspetto fondamentale è che un 
SyncAdapter è comunque collegato a una particolare tipologia di contatto che abbiamo specificato 
attraverso un opportuno documento XML. Ogni sycnAdapter dispone di logica, la quale dipende 
dalle operazioni che si intendono eseguire. Nel nostro caso si tratta di uno scenario molto semplice, 
che consiste nell'invio di alcuni dati al server per poi aggiornarne lo stato localmente. Questa 
operazione può prevedere la verifica di alcune credenziali, compito che possiamo delegare 
all'AccountManager. Ilpasso successivo nella realizzazione di un syncAdapter consiste proprio nella 
definizione della logica corrispondente, che dovrà essere implementata nel seguente metodo della 

classe astratta Abstract ThreadedSyncAdapterl 

public void onPerf ormSync (Account account, Bundle extras, String authority, 

ContentProviderClient contentProviderClient , SyncResult syncResult) 

Notiamo come nella firma del metodo compaiano il riferimento a un account e all' authority del 
content provider di riferimento. Oltre al parametro relativo agli extra che ogni evento di scheduling 
può ricevere e che può essere impostato attraverso il metodo addPeriodicSync o del content 
resolver visto in precedenza, il sistema ci permette di ottenere il riferimento a un 

ContentProviderClient e a un Oggetto di tipo SyncResult. La classe ContentProviderClient 

rappresenta l'insieme di operazione che è possibile eseguire per l'interazione con un content provider, 
che in questo caso sarà quello impostato. L'oggetto che viene passato come parametro è quello 
ottenuto dal content resolver attraverso l'invocazione del metodo 

public final ContentProviderClient acquireContentProviderClient (String authority) 

a cui viene passato il nome dell' authority del content provider associato. Una volta ottenuto questo 
riferimento e utilizzato il ContentProviderClient, è sempre bene invocare su di esso il metodo 

release ( ) . 
NOTA 

Di solito, al posto di questo riferimento, si utilizzano direttamente le operazioni del content resolver, 
di cui è possibile ottenere il riferimento attraverso il Context. 

Molto più importante è invece il significato dell'oggetto di tipo SyncResult, in quanto permette a 
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ciascun syncAdapter di informare il sistema, o meglio ciò che viene rappresentato dal syncManager, 
dell'esito dell'operazione di sincronizzazione. In base allo stato di questo oggetto il syncManager potrà 
infatti decidere se programmare un'altra operazione di sincronizzazione o meno. La logica di come le 
informazioni vengono gestite è contenuta nel metodo onFinishedo della classe synccontext del 
package android. content, la quale invoca a sua volta un metodo omonimo definito dall'interfaccia 
aidl la cui implementazione è fatta in modo nativo. Il compito di ogni syncAdapter sarà quello di 
valorizzare le proprietà del syncResuit in modo che il syncManager possa decidere se riprovare 
oppure no. Se l'operazione di sincronizzazione ha successo, l'oggetto verrà lasciato inalterato. Nel 
caso in cui si presentassero degli errori esistono invece delle proprietà che permettono di specificare 
se l'errore è lieve (soft) o grave (hard). Nel primo caso il syncManager ritenterà la sincronizzazione 
aumentando, di volta in volta, l'intervallo tra i tentativi Nel caso di errori gravi la sincronizzazione non 
verrà più ritentata a meno che non sia stato specificato un extra associato alla costante 
contentResoiver . sync_extras_upload. In questo caso particolare, un errore di tipo hard 
provocherà un unico tentativo. Gli errori gravi avranno la priorità rispetto a quelli lievi. Un tipico caso 
di errore grave si ha quando il SyncAdapter non riesce ad accedere al content provider, o alla base 
dati in genere, cosa che dovrà essere segnalata al SyncManager impostando il valore della proprietà 
booleana databaseError a true. Essendo un errore grave, lo scheduling non verrà ripetuto in modo 
automatico. In altri casi potrebbe succedere che un syncAdapter intelligente comprenda che la 
frequenza di variazione delle proprie informazioni non giustifichi la frequenza di sincronizzazione 
impostata. Potrebbe quindi essere utile dire al syncManager di ritardare il successivo evento di 
scheduling relativo allo stesso account e alla stessa authority impostando il valore della proprietà 
deiayuntu a una quantità espressa in secondi. Un'esigenza opposta potrebbe essere quella di 
richiedere un altro evento di scheduling immediato impostando a true il valore della proprietà 
f uiisyncRequested. Qui il SyncManager non farà altro che inviare subito una richiesta di 
sincronizzazione analoga senza ripetere però le stesse informazioni relative agli extra, che nel secondo 
caso sarebbero vuoti. Attraverso la proprietà syncAireadyinProgress è invece possibile informare il 
sistema della volontà di "saltare un giro", ovvero di non elaborare questo evento di scheduling ma di 
elaborare eventualmente il successivo. Si tratta del caso in cui è, per esempio, già attiva 
un'operazione di sincronizzazione, che potrebbe anche non interessare la stessa authority o lo stesso 
account. Attraverso la proprietà tooManyRetries possiamo indicare al SyncManager che sono stati 
eseguiti diversi tentativi di sincronizzazione senza successo. In questo caso il sistema si comporterà 
come se si fosse verificato un errore grave e non tenterà nuovamente la sincronizzazione. Un ultimo 
flag si utilizza nel caso in cui il syncAdapter si accorge di dover eseguire un numero elevato di richieste 
al server per la cancellazione di un insieme di elementi Impostando a true il valore della proprietà 
tooManyDeietions il SyncManager visualizzerà una notifica chiedendo all'utente cosa fare. Questi 
potrà decidere di proseguire con l'invio delle richieste, annullare tutte le operazioni o non fare nulla. 
Nel primo caso l'evento di scheduling verrà ripetuto ottenendo un extra associato alla costante 
ContentResoiver . sync_extras_override_too_many_deletions, mentre nel secondo caso la 
costante sarà contentResoiver. sync_extras_discard_local_deletions. Sarà responsabilità della 
particolare implementazione del syncAdapter decidere come gestire i vari casi 

Oltre a queste proprietà di tipo booleano ne esiste una che definisce un insieme di dati a scopo 
informativo. Per esempio, attraverso numAuthExceptions si può specificate il numero di errori di 
autenticazione, mentre attraverso numioExceptions è possibile specificare il numero di errori dovuti 



582 



alle operazioni di I/O. Nella nostra implementazione sarà questo il tipo di informazioni che forniremo 
nel caso di errori 

Nel nostro progetto l'obiettivo è quello di realizzare un syncAdapter per la sincronizzazione delle 
informazioni inserite dall'utente, logica che abbiamo incapsulato nella classe ughoSyncAdapter, la 
quale sostanzialmente esegue queste due operazioni: 

• ottenere l'informazione relativa al token per l'account da sincronizzare; 

• eseguire l'operazione di sincronizzazione 

che abbiamo implementato nel seguente modo: 

public class UghoSyncAdapter extends AbstractThreadedSyncAdapter { 
private Context mContext; 

public UghoSyncAdapter (final Context context) { 
super (context, true); 
this . mContext = context; 

} 

@Override 

public voìd onPerf ormSync (Account account, Bundle bundle, String s, 

ContentProviderClient contentProviderClient , 

SyncResult syncResult) { 
String authToken = nuli; 
try { 

authToken = 

AccountManager . get (mContext ) . blockingGetAuthToken (account , 

AccountConst . UGHO_TOKEN_TYPE , true ) ; 
// NOTA: la nostra implementazione non usa account. 
Synchronizer . syncLocalData (mContext) ; 

} catch (AuthenticatorException e) { 
e .printStackTrace ( ) ; 

syncResult . stats . numAuthExceptions++; 
} catch (OperationCanceledException e) { 

e . printStackTrace ( ) ; 
} catch (IOException e) { 

e . printStackTrace ( ) ; 

syncResult . stats . numIoExceptions++; 

} 

} 

} 

Come accennato all'inizio del paragrafo, si tratta di un esempio molto semplice la cui operazione di 
sincronizzazione non utilizza neppure F informazione di token che abbiamo ottenuto attraverso 
l'invocazione del metodo 

public String blockingGetAuthToken (Account account, String authTokenType, 
Boolean notifyAuthFailure) 

Molto interessante è il parametro notifyAuthFailure, che permette di richiedere le credenziali 
all'utente nel caso in cui queste non fossero verificate. Questo è il motivo per cui il valore di questo 
parametro qui sarà true. Il sistema comunicherà infatti il problema di autenticazione attraverso una 
notifica selezionando la quale l'utente potrà inserire nuovamente le proprie credenziali per la richiesta 
del nuovo token. Nel nostro caso un errore di autenticazione è considerato come grave, per cui il 
syncManager non ritenterà più la sincronizzazione a meno che l'utente non riconfiguri la cosa nelle 
opzioni del dispositivo. L'utilizzo del token come informazione obbligatoria e quindi l'utilizzo del 
relativo codice digestione dell'errore dipenderà naturalmente dal tipo di applicazione. 

Relativamente a un valore false per il parametro notifyAuthFailure, la documentazione dice che 
il sistema dovrebbe visualizzare unprompt per l'inserimento immediato delle credenziali per poi 
proseguire con la sincronizzazione. In realtà questo non succede in quanto l'invocazione del metodo 
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biockingGetAuthToken ( ) permette l' invocazione sincrona di getAuthToken ( ) , la quale, per lo stesso 
parametro, dice che un valore false indica che la gestione delle credenziali è lasciata allo 
sviluppatore. Questo è infatti quello che succede. Si tratterebbe comunque di un comportamento 
possibile grazie al fatto che il metodo è, come dice il nome, bloccante, ovvero non procede finché non 
si è in grado di fornire un valore per il token, nuli oppure no. Sottolineiamo comunque come si tratti 
di un'operazione che non dovrebbe mai essere eseguita nelthread principale dell'applicazione. Da 
questo punto divista, il syncAdapter rappresenta il luogo dove l'operazione può essere eseguita in 
tutta sicurezza. 

Definizione del service per il SyncAdapter 

Per completare il nostro syncAdapter manca ancora un ultimo passo fondamentale, ovvero la 
realizzazione di un servizio che permetta al sistema di interagire con la nostra implementazione. A tale 
proposito è quindi necessario creare una specializzazione della classe Service la cui responsabilità 
sarà quella di fornire, attraverso Yoverride del metodo onBindo, lo stub dell'implementazione. Nel 
nostro progetto abbiamo creato la classe ughoSyncService come segue: 

public class UghoSyncService extends Service { 

private static final Object mMutex = new ObjectO; 

private static UghoSyncAdapter mUghoSyncAdapter = nuli; 

public void onCreateO { 

synchronized (mMutex) { 
ìf (mUghoSyncAdapter 
mUghoSyncAdapter 

} 

} 

} 

public IBinder onBind ( Intent intent) { 

return mUghoSyncAdapter . getSyncAdapterBinder ( ) ; 

} 

} 

Come abbiamo visto in occasione della creazione di altri servizi, il metodo oncreate ( ) viene 
invocato in fase di creazione dello stesso. È quindi un buon punto in cui inizializzare i vari componenti 
che lo stesso servizio dovrà gestire. In questo caso, nel metodo oncreate ( ) , abbiamo inizializzato 
un'istanza della classe UghoSyncAdapter, ovvero della nostra implementazione di SyncAdapter 
descritta nei paragrafi precedenti. Notiamo come il costruttore preveda come unico prametro il 
riferimento al Context dell'applicazione. Infine, vediamo come il metodo onBind ( ) non faccia altro 
che ritornare il risultato dell'invocazione del metodo getSyncAdapterBinder o sulla nostra istanza di 
adapter. Si tratta dello stub che il syncManager utilizzerà per interagire con la nostra istanza, che viene 
creata in un processo diverso da quello del syncManager stesso. 

La parte più importante nella definizione del servizio riguarda però la sua configurazione all'interno 

dell' AndroidManif est . xml! 

<service android: name=" .account .UghoSyncService" 
android: exported="true" 
android:process=" : sync"> 
<intent-f ilter> 

<action android: name=" android. content . SyncAdapter" /> 
</intent-f ilter> 

<meta-data android : name=" android . content . SyncAdapter" 
android: resource="@xml/ugho_sync_adapter"/> 

584 



== nuli) { 

= new UghoSyncAdapter (getApplicationContext ()) ; 



</ service> 

Come tutti i servizi, anche quello di sincronizzazione viene definito attraverso un elemento di tipo 
<service/>, di cui è possibile specificare l'implementazione attraverso l'attributo android: name. Qui 
assumono importanza anche i valori degli attributi android :exported e android:process. Il primo 
consente anche alle altre applicazioni (e quindi agli altri processi) di interagire con il servizio, mentre il 
secondo permette di specificare il nome del processo che lo andrà a eseguire. Ciò che definisce 
questo componente come un servizio di sincronizzazione è invece l'action associata al valore 
android . content . SyncAdapter . Di seguito abbiamo la dichiarazione di alcune informazioni che ci 
permettono di legare il servizio ai documenti XML creati all'inizio del nostro lavoro. Attraverso un 
metadato di nome android. content. SyncAdapter SI fa riferimento al documento XML che descrive il 
SyncAdapter. Sempre in relazione al file AndroidManif est . xml, è bene ricordare che le operazioni di 
sincronizzazione necessitano della seguente definizione per la richiesta del permesso corrispondente: 

<uses-permission android: name=" android. permi ss ion . WRITE_SYNC_SETTINGS" /> 

Lasciamo al lettore la verifica di come la creazione di un nuovo account porti ora alla creazione di 
un modulo di sincronizzazione come quello nella Figura 13.28 e di come l'evento discheduling 
comporti effettivamente l'esecuzione del task corrispondente. 




ACCOUNT 



xO Ultima sincronizzazione: 23/07/201 3 
12:45 

AUTHENTICATOR CONFIGURATION 

UGHO Account 

Inserì here the Authentication Server URL 



Figura 13.28 Attivazione dell'operazione di sincronizzazione. 



Conclusioni 

In questo capitolo abbiamo analizzato diversi aspetti di una funzionalità molto importante nelle 
applicazioni attuali, ovvero la gestione degli utenti e i task di sincronizzazione. Inizialmente abbiamo 
sostituito la nostra gestione del login con quella standard di Android, che prevede l'utilizzo di un 
componente standard chiamato AccountManager. Successivamente abbiamo usato l'SDK di 
Facebook per utilizzare il sistema di autenticazione del social network. In questa fase abbiamo anche 
visto come configurare un'applicazione Facebook e come ottenere le informazioni di cui si è chiesta 
l'autorizzazione all'utente. Abbiamo infine descritto come integrare la gestione degli account di 
Android con il meccanismo nativo di sincronizzazione che ha in SyncAdapter la sua classe principale. 
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Capitolo 14 



Location e mappe 



In questo capitolo conclusivo del libro ci occuperemo di un argomento molto importante, ovvero la 
localizzazione e l'utilizzo delle mappe e in particolare delle Google Maps. Si tratta di una delle poche 
novità presentate all'ultima Google IO 2013, ed è stata inglobata all'interno di quelli che si chiamano 
Google Play Services, che impareremo a configurare nel nostro Andro id Studio. Attraverso la 
realizzazione di una nuova applicazione (che abbiamo chiamato WakeMe), vedremo come generare 
degli alert quando ci si avvicina a una particolare regione o zona. Aggiungeremo anche la possibilità 
non solo di capire quando siamo in certe zone ma anche di sapere in che modo ci arriviamo 
sfiuttando una delle ultime feature, ovvero 1' activity recognition. 

Creazione del progetto e installazione di Google 

Play SDK 

Il primo passo verso l'utilizzo dei Google Play Services consiste nel verificarne la presenza 
attraverso un tool che abbiamo già visto Capitolo 1 e che si chiama SDK Manager e che possiamo 
attivare attraverso il pulsante nella Figura 14.1. 

A questo punto è sufficiente andare nella parte finale della lista dedicata, Extras, selezionare la 
voce Google Play services e lare clic sul pulsante Instali (Figura 14.2). 



:>tuaioKrojecis/uui-iuj - 


P: 


! I* A * 


! ? 
• 




SDK Manager 







Figura 14.1 SDK Manager per il download delle librerie. 
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Android 1.5 (API i) 



T Extras 



□ 


kld Android Support Repository 


1 


* Nof installed 


□ 


«hi Android Support Library 


13 


dKi Installed 


□ 


<U Coogle AdMob Ads SDK 


iJ 


* Not installed 


□ 


Si Coogle Analytics App Tracking SDK 


3 


* Not installed 


□ 


eU Coogle Cloud Messaging for Android Library 


3 


♦ Not installed 


Ci 


*." Coogle Play services 


7 


* Not installed 




«U Coogle Repository 


1 


* Not installed 


□ 


icU Coogle PlayAPK Expansion Library 


3 


* Not installed 


□ 


*ki Coogle Play Billing Library 


4 


« Not installed 


□ 


Coogle Play Licensing Library 


2 


« Not installed 


□ 


dsi Coogle USB Driver 


7 


9 Not compatible with Mac C 




*k Coogle Web Driver 


2 


+ Nor installed 


□ 


*U Intel x86 Emulator Accelerator (HAXM) 


3 


■r Not installed 



Show; V Updates/New V Installed Obsolete Select New or U pdales [ Instali 2 packages... | 

Sort by: • API level Repository DeselectAII Delete 1 package... 



Figura 14.2 Selezioniamo la voce Google Play services nelI'SDK Manager. 

Dopo aver accettato le licenze noteremo la presenza della libreria scaricata all'interno della cartella 
<android-sdk>/extras/google/google_play_services/, dove con <androìd-sdk> indichiamo la 
directory di installazione dell'ambiente Android. Come detto in precedenza, Android Studio è in 
continuo aggiornamento e, speriamo, miglioramento, per cui anche le modalità di configurazione 
potrebbero essere diverse. In ogni caso, proprio mentre scrivevo è uscito un update che prevede di 
gestire i Play Services e la libreria di compatibilità in modo quasi automatico. Per farlo dobbiamo 
ritornare neWSDK Manager e scaricare, se non già fatto, anche le librerie evidenziate nella Figura 
14.3. 

A questo punto andiamo a modificare il file di nome buìid.gradie più esterno nel seguente modo: 

buildscript { 

repositories { 

mavenCentral ( ) 

} 

dependenoies { 

classpath 1 com. android . tools . build : gradle : 0 . 5 . + ' 

} 

} 
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Android SDK Manager 



SDK Path: /Applicattons/Android Studio. app/sdk 



W Name 

► C2 Android 3.1 (API 12) 
j ► CSAndroid 3.0 (API 11) 

► ^.Android 2.3.3 (API 10) 

► Ci Android 2.2 (API 8) 

► CSAndroid 2.1 (API 7) 

► GiAndroid 1.6 (API 4) 

► [^Android 1.5 (API 3) 
T Extras 



API 



Rev. Status 





♦ Android Support Repository 


1 


Not installed 




a Android Support Library 


13 


Installed 




□ Coogle AdMob Ads SDK 


11 


Not installed 


1 


a Coogle Analytics App Tracking SDK 


3 


Not installed 




□ Coogle Cloud Messaging for Android Library 


3 


Not installed 




□ Coogle Play services 


7 


& Installed 




D Coogle Reposi tory 


1 


Nof installed 


□ 


□ Coogle Play APK Expansion Library 


3 


Not installed 


□ 


D Coogle Play Billing Library 


4 


Not installed 


□ 


O Coogle Play Licensing Library 


2 


Not installed 


□ 


Q Coogle USB Driver 


7 


Not compatible with Mac C 


□ 


□ Coogle Web Driver 


2 


Not installed 


□ 


O Intel x86 Emulator Accelerator (HAXM) 


3 


Not installed 



Show: Vupdates/New •/ Installed Obsolete Salaci New or Uodates 
Sort by: • API level Reposltory Deselect AH 

Done loading packages. 



Instali 2 packages.. 



Oelete packages.. 



o -• 



Figura 14.3 Download dei repository locali relativi alle librerie utilizzare da Gradle per il build. 

Il plug-in mette a disposizione le diverse librerie direttamente attraverso il repository che abbiamo 
scaricato, per cui la precedente definizione è sufficiente. Il file build. gradle di livello inferiore diventa: 

buildscript { 

repositories { 

mavenCentral () 

} 

} 

apply plugin: 'android' 

dependencies { 

compile ' com. google . android. gms :play-services : 3 . 1 . 36 ' 

} 

android { 

compileSdkVersion 17 
buildToolsVersion "17.0.0" 

def aultConf ig { 

minSdkVersion 8 
targetSdkVersion 17 



dove abbiamo messo in evidenza la presenza della definizione della dipendenza con i Google Play 
Services. 

Il passo successivo consiste nelT impostare Proguard, che sappiamo essere un tool per 
P offuscamento del codice che viene automaticamente utilizzato dal plug-in di Android in Gradle se 
attivato nel seguente modo nel precedente file di configurazione: 

buildscript { 

repositories { 
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mavenCentral ( ) 

} 

} 

apply plugin: 'android' 

dependencies { 

compile ' com. google . android. gms : pi ay- servi ce s : 3 . 1 . 36 ' 

} 

android { 

buìldTypes { 
release { 

runProguard true 

proguardFile ' my__proguard_settings . txt ' 

} 

} 

compileSdkVersion 17 
buildToolsVersìon "17.0.0" 

def aultConf ig { 

minSdkVersion 8 
targetSdkVersion 17 

} 

} 

Nella parte evidenziata abbiamo detto a Gradle che nel caso di Buiid dell'applicazione nella 
versione di release, il file di configurazione di Proguard sarà quello di nome 
my_proguard_settings . txt nella cartella principale di tutto il progetto. Al file classico che viene 
utilizzato e che abbiamo preso dalla cartella dell' SDK abbiamo dovuto aggiungere la definizione 

-keep class*extends java . util . ListResourceBundle { 
protectedOb ject [ ] [] getContents ( ) ; 

} 

che ci permetterà di non offuscare le classi della libreria che non vengono, di default, riconosciute 
come appartenenti al sistema Android. 

Abbiamo così creato il nostro progetto e installato la libreria per poter utilizzare i servizi di Google 
Play. Esiste però un ulteriore passo, dovuto al fatto che l'utilizzo della libreria richiede l'installazione 
del corrispondente APK, che Google comunque mantiene aggiornato con opportuni update 
attraverso il Google Play Store. Si tratta di un'applicazione che esegue, in background, tutta una 
serie di servizi di cui la precedente libreria rappresenta la parte client. È importante ricordare che 
sono servizi che possono funzionare dalla versione 2.2 della piattaforma. 

Sebbene Google cerchi, attraverso il Google Play Store, di mantenere questo APK aggiornato, 
potrebbe succedere che la versione sul dispositivo non sia l'ultima o comunque non quella compatibile 
con la libreria client installata con l'applicazione. È regola generale eseguire un controllo di 
compatibilità all'avvio dell' applicazione e precisamente all'interno del metodo onResume ( ) dell' activity 
principale. Il caso migliore {happy path) è quello che prevede che sia l'applicazione sia l'APK 
installato nel dispositivo siano dell'ultima versione disponibile. Fortunatamente lo stesso Google Play 
SDK fornisce alcuni tool per capire se è necessario un download dell' APK e quindi mandare l'utente 
in modo automatico al Play Store per il download. 

NOTA 

Per testare l'applicazione sull'emulatore è importante utilizzare almeno la versione 4.2.2 con 
l'utilizzo delle librerie di Google. 

Nel caso specifico abbiamo utilizzato questo codice, che poi completeremo nelle parti di interesse: 
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SOverride 

protected void onResumeO { 
super . onResume ( ) ; 

final int checkPlayStatus = GooglePlayServicesUtil 

. isGooglePlayServicesAvailable (this) ; 

if (checkPlayStatus == ConnectionResult . SUCCESS) { 

Log. d (TAG_LOG, "Everything is ok ! " ) ; 
} else { 

mErrorDialog = GooglePlayServicesUtil 

. getErrorDialog (checkPlayStatus , this , 
PLAY_DOWNLOAD_REQUEST_ID , 
new Dialoglnterface.OnCancelListener () { 

gOverride 

public void onCancel (Dialoglnterf ace dialog) { 
// L'SDK è obbligatorio 
finish () ; 

} 

}); 

mErrorDialog . show ( ) ; 

} 

} 

@Override 

protected void onActivityResult (int requestCode, int resultCode, Intent data) { 
if (requestCode == PLAY_DOWNLOAD_REQUEST_ID) { 
if (resultCode == Activity . RESULT_OK) { 

Log. d (TAG_LOG, "Result OK!"); 
} else if (resultCode == Activity . RESULT_CANCELED) { 

Log . d ( TAG_LOG, "Cancelled! ") ; 
} else { 

Log. d (TAG_LOG, "Dunno ! ! " ) ; 

} 

} 

} 

Attraverso il metodo statico isGooglePlayServicesAvailable o sipuò verificare la disponibilità 
dell'SDK nel dispositivo. In caso di successo il valore di ritorno, di tipo intero, sarà quello della 
costante ConnectionResult . success. In caso contrario significa che l'ultima versione non è 
disponibile. In questo caso l'SDK ci viene incontro dandoci la possibilità di ottenere direttamente la 
finestra di dialogo da visualizzare per il download attraverso le seguenti istruzioni; 

Dialog dialog = GooglePlayServicesUtil . getErrorDialog (checkPlayStatus, 
this, PLAY_DOWNLOAD_REQUEST_ID) ; 

dialog . show ( ) ; 

Notiamo come il metodo di creazione della finestra di dialogo preveda anche la definizione di un 
identificatore della richiesta, che utilizzeremo per conoscere l'esito del download che andiamo a 
gestire nel metodo di callback onActivityResult ( ) , come ormai consuetudine. È bene ricordare 
comunque che quando l'applicazione non è disponibile e quindi viene scaricata dal Play Store a 
seguito dell'utilizzo diDiaiog, si ha il ritorno all'applicazione che lo ha richiesto. Questo consente 
l'invocazione del metodo InActivityResuit o ma anche la nuova esecuzione del metodo 
onResume ( ) , che questa volta avrà successo permettendo il normale flusso dell'applicazione. Il 
metodo InActivìtyResuit ( ) rappresenta un ulteriore punto di estensione per eseguire determinate 
operazioni a seconda dell'esito del download. 

Per testare l'applicazione, consigliamo al lettore di disinstallare l'eventuale applicazione Google 
Play Services dal proprio dispositivo utilizzando il normale gestore delle applicazioni nei Settings. 

NOTA 

Questa operazione provocherà molto probabilmente una qualche notifica legata ad altre applicazioni 
che necessitano dello stesso APK. Uno di questi è sicuramente l'applicazione Hangout, se 
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installata. 

Lanciando l'applicazione otterremo la visualizzazione della finestra di dialogo mostrata nella Figura 
14.4. 

Selezionando il pulsante Aggiorna verrà visualizzata la pagina corrispondente in Google Play per 
l'aggiornamento o il download dell'ultima versione disponibile (come nella Figura 14.5). 

È importante sottolineare come la pressione del pulsante Back in corrispondenza della 
visualizzazione della finestra di dialogo non provochi l'invocazione del metodo InActivityResuit o , 
la quale richiede la visualizzazione dell'attività del Play Store. Per questo motivo abbiamo utilizzato un 
overload del metodo getErrorDiaiog o acui serve anche Un OnCancelListener, che di fatto chiude 
l'applicazione in quanto una libreria necessaria non è disponibile. 

Facciamo osservare che affinché l'applicazione si accorga dell' SDK questo dev'essere 
completamente installato. Nel caso in cui fosse in corso il download o l'installazione non fosse 
completata è come se lo stesso non fosse disponibile. Questo significa che la pressione del pulsante 
Back durante l'installazione o il download dell'SDK viene interpretata come una cancellazione della 
stessa. 



© W A 53 O ? * ^d I 1 1 46 

£ WakeMe 



Hello world 1 




Figura 14.4 Messaggio di richiesta di download dell'applicazione associata ai Google Play 
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Services. 



Collegato come dispositivo multimediale 




Google Play services 

GOOGLE INC. ❖ 



AGGIORNA 



^ e, a 



Figura 14.5 I Google Play Services nel Play Store. 



La prima schermata: visualizziamo la posizione corrente 

Una volta risolto il problema dell'installazione di tutto ciò che ci serve per l'utilizzo dei servizi 
Google Play ci accingiamo alla realizzazione della prima schermata, la quale dovrà semplicemente 
visualizzare una mappa centrata nella posizione attuale. Quando i Google Play Services non erano 
disponibili ogni applicazione era responsabile del reperimento della posizione attuale attraverso delle 
opportune API. In seguito sono state fatte delle ottimizzazioni ma solo ora ci si è accorti che dato il 
numero elevato di applicazioni che necessitavano di questa informazione era forse buona cosa 
centralizzare il dato e renderlo quindi accessibile attraverso delle API comuni che, in questo contesto, 
hanno nella classe LocationClient del package oom . google . android . gms . location lo strumento 
principale. L'accuratezza del valore dipenderà poi da quelli che saranno i permessi e i sensori che il 
sistema avrà a disposizione in quel particolare momento. In relazione ai permessi esistono due diversi 
livelli di accuratezza che possiamo associare ai seguenti valori: 

AC CES S_COARSE_LOCAT I ON 
AC CE S S_F I NE_LOC AT I ON 

Il primo permette di determinare la posizione utilizzando le sorgenti Wi-Fi oppure le celle che il 
dispositivo riesce a cogliere. Il secondo livello, che comprende anche il primo, prevede invece di 
individuare la posizione attraverso l'utilizzo delle sorgenti precedenti a cui va aggiunto il GPS. 
Esistono due diversi livelli di accuratezza che prevedono costi e consumi diversi Per esempio, 
l'utilizzo del GPS è molto dispendioso. Il livello di accuratezza dipenderà da quello che è l'obiettivo 
dell'applicazione. Un'applicazione di tracciamento del percorso di ima corsa necessiterà di 
un' accuratezza fine, a differenza di un' applicazione che intende solamente sapere se si è in prossimità 

592 



di una particolare città o meno. La cosa non è documentata ma ci aspettiamo che il fatto di 
centralizzare rinformazione relativa alla posizione faccia in modo che se una sola delle applicazioni 
utilizza un'accuratezza fine, anche le altre applicazioni ne traggano vantaggio. La responsabilità di 
avere sempre rinformazione migliore è comunque delegata ai servizi di Google Play. Aggiungiamo 
allora le seguenti definizioni all' AndroidManif est . xml 

<uses-permission android : name="android .permission . ACCESS_COARSE_LOCATION" /> 
<uses-permission android : name=" android .permission . ACCESS_FINE_LOCATION" /> 

per l'utilizzo della location con la massima accuratezza possibile. 

Come già detto, il componente che abbiamo a disposizione si chiama Locationciient; per poter 
essere utilizzato, deve avere una connessione verso l'SDK dei servizi di Google Play. Per questo 
motivo si rende necessaria l'implementazione di un meccanismo che permetta di gestire questa 
connessione e gli eventuali errori che ne possono scaturire. Come il lettore ormai si aspetterà, si tratta 
di un meccanismo di callback per la notifica dell'avvenuta inizializzazione o della presenza di errori. 
Anche stavola le API ci forniranno un meccanismo per porvi rimedio. 

NOTA 

È un pattern ormai comune nella gestione dei servizi di Google. Un meccanismo analogo si ha, per 
esempio, nella gestione dei servizi di Google Plus. 

La prima interfaccia per la gestione dello stato di connessione si chiama 

GooglePlayServicesClient . ConnectionCallbacks 

e prevede la definizione delle seguenti operazioni di ovvio significato: 

public void onConnected (Bundle dataBundle) 
public void onDìsconnected ( ) 

Si tratta dei metodi che vengono invocati in caso di successo. In caso di errore viene infatti 
invocato un metodo descritto dall'interfaccia di nome 

GooglePlayServicesClient . OnConnectionFailedListener 

la cui firma è 

public void onConnectionFailed (ConnectionResult connectionResult ) 

dove il parametro di tipo connectionResult conterrà tutte le informazioni necessarie alla gestione 
del problema. Anche qui esiste un pattern abbastanza classico di gestione dell'errore. E infatti lo 
stesso oggetto di tipo connectionResult che, attraverso il suo metodo hasResoiution o , ci dice se 
esiste una soluzione al problema oppure no. In caso affermativo lo stesso ConnectionResult CI 
consentirà di lanciare il componente con la UI o il servizio risolutivo. In caso contrario ci fornirà 
comunque ulteriori informazioni sul problema attraverso un opportuno codice. 

Per essere concreti, la nostra app Reazione definisce questa prima implementazione dell'interfaccia 
di gestione dello stato di connessione 

private GooglePlayServicesClient . ConnectionCallbacks mConnectionCallbacks 
= new GooglePlayServicesClient . ConnectionCallbacks ( ) { 

SOverride 

public void onConnected (Bundle bundle) { 

Log. d (TAG_LOG, "Connected with Google Play Services"); 
Toast .makeText (MainActivity . this, "Connected" , 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

SOverride 

public void onDìsconnected ( ) { 

Log. d (TAG_LOG, "Disconnected with Google Play Services"); 
Toast .makeText (MainActivity . this, "Disconnected" , 
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Toast . LENGTH_SHORT) . show ( ) ; 

} 

}; 

e quindi la seguente per la gestione dell'errore 

private GooglePlayServicesClient . OnConnectionFailedListener 
mOnConnectionFailedListener = 

new GooglePlayServicesClient . OnConnectionFailedListener ( ) { 
@Override 

public void onConnectionFailed (ConnectionResult connectìonResult ) { 
// Qui annulliamo se ConnectionResult ha una soluzione al problema 
if (ConnectionResult . hasResolution () ) { 

// Qui abbiamo una soluzione quindi iniziamo l'activity correlata 
try { 

// Inizia un'activity che prova a risolvere l'errore 
ConnectionResult . startResolutionForResult (MainActivity . this, 

CONNEC T I ON_F AI LURE_RE SOLUTI ON_RE QUE S T ) ; 
// Il metodo precedente dovrebbe generare un'eccezione se 
// Services ha cancellato 1 ' intent . 
} catch ( IntentSender . SendlntentException e) { 

// Dobbiamo gestire questo errore. Mostriamo un toast 

Toast . makeText (MainActivity . this, "Resolution Intent deleted!", 

Toast . LENGTH_SHORT ) . show ( ) ; 
e . printStackTrace ( ) ; 

} 

} else { 

// In questo caso non c'è soluzione, quindi ci limitiamo 
// a mostrare un messaggio 

Toast .makeText (MainActivity . this , "Error with code " + 

ConnectionResult . getErrorCode ( ) , Toast . LENGTH_SHORT) . show ( ) ; 

} 

} 

}; 

Serve impunto dipartenza in cui richiediamo al Locationciient di iniziare la connessione. Èun 
meccanismo che dovrà essere legato al ciclo di vita della nostra activity. Il pattern più idoneo prevede 
che venga creata un'istanza del Locati onClient all'interno del metodo oncreate ( ) e poi richiesta una 
disconnessione nel metodo onStart ( ) . Il metodo onstop ( ) è invece il metodo più idoneo per la 
richiesta di chiusura della connessione. È bene precisare che la connessione o disconnessione del 
nostro client ai servizi non è in alcun modo legata al reperimento o meno della posizione o di altre 
informazioni correlate. Come in altri contesti, un server è in esecuzione anche se non vi sono client 
connessi; qui il server è gestito dal sistema in modo, si spera, ottimizzato. 

Nel caso specifico la creazione delLocationciient nel metodo oncreate o avviene nel seguente 
modo utilizzando un costruttore che, oltre all'immancabile Context, necessita dei riferimenti alle 
implementazioni delle interfacce di callback descritte sopra: 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R . layout . activity_main) ; 

mLocationClient = new LocationClient (this, mConnectionCallbacks , 
mOnConnectionFailedListener) ; 

} 

L'avvio della connessione e la chiusura della stessa avvengono invece nei metodi onstart o e 

onStop ( ) I 
SOverride 

protected void onStartO { 
super . onStart () ; 

// Connettiamo il LocationClient 
mLocationClient . connect () ; 

} 

SOverride 
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protected void onStopO { 

// Disconnettiamo il LocationClient 
mLocationClient . disconnect () ; 

super . onStop ( ) ; 

} 

Nel codice precedente possiamo vedere come nel metodo onstop < ) vi sia prima l'invocazione del 
metodo disconnect () e poi l'invocazione dell'analogo metodo della classe padre attraverso il 
riferimento super. Non vi è una ragione particolare per questo se non quello di dare una certa 
"simmetria" rispetto a quanto avviene nel metodo onstart ( ) . 

Una volta eseguita la connessione siamo quindi pronti a utilizzare i servizi offerti dall'oggetto 
LocationClient tra cui la posizione corrente attraverso il metodo getLastLocation o . Ricordiamo 
che si tratta di un metodo che ritorna quella che è l'ultima posizione ottenuta compatibilmente con 
quelle che sono le configurazioni e i permessi impostati per l'applicazione. Nel nostro caso 
aggiungiamo la visualizzazione di questa informazione all'interno del metodo onconnectedo del nostro 
oggetto di callback, che diventa il seguente: 

private GooglePlayServicesClient . ConnectionCallbacks mConnectìonCallbacks 
= new GooglePlayServicesClient . ConnectionCallbacks ( ) { 

@Override 

public void onConnected (Bundle bundle) { 

Log. d (TAG_LOG, "Connected with Google Play Services"); 

Toast .makeText (MainActivity . this, "Connected", Toast . LENGTH_SHORT) . show ( ) ; 
// Mostriamo currentLocation 

mCurrentLocation = mLocationClient . getLastLocation () ; 

Toast . makeText (MainActivity . this, "Last Location: " + mCurrentLocation, 
Toast .LENGTH_SHORT) . show ( ) ; 

} 

@Override 

public void onDisconnected() { 

Log . d (TAG_LOG, "Disconnected with Google Play Services"); 
Toast . makeText (MainActivity .this, "Disconnected" , 
Toast . LENGTH_SHORT) . show ( ) ; 

} 

}; 

Concludiamo il paragrafo osservando solo che al momento della connessione la posizione 
potrebbe non essere subito disponibile, ma a questo problema owieremo nel prossimo paragrafo. Al 
momento, se questo dovesse avvenire, basterà ruotare il dispositivo per indurre una nuova 
connessione e presumibilmente la visualizzazione di una posizione che il sistema ha avuto modo di 
reperire a seguito delle richieste precedenti 

Aggiornare le informazioni sulla location 

Nel paragrafo precedente abbiamo visto che F informazione relativa alla location ottenuta attraverso 
l'istruzione 

mCurrentLocation = mLocationClient . getLastLocation () ; 

potrebbe non essere subito disponibile, da cui un valore nuli per la variabile l CurrentLocation. 
Fortunatamente Andro id fornisce due meccanismi che ci permettono di essere avvisati degli 
spostamenti del nostro dispositivo. Il primo è basato sul concetto di callback, mentre il secondo è 
stato presentato aU' ultima Google IO del 20 13 e prevede l'utilizzo di una serie diintent che 
contengono anche informazioni sulla "qualità" del movimento. Come vedremo, attraverso questo 
nuovo meccanismo, che si chiama activity recognition, sarà possibile sapere se l'utente sta 
camminando, correndo oppure utilizzando un mezzo di locomozione. In questo paragrafo ci 
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occuperemo del primo metodo, che permette di soddisfare la maggior parte dei casi d'uso. Il 
meccanismo è quello classico basato sull'implementazione di un listener, che in questo caso è definito 

dall'interfaccia LocationListener del package com.google.android.gms. location (da non 

confondere con quella dell'ambiente classico di Andro id che appartiene invece al package 
android. location), la quale prevede la definizione dell'operazione: 

public void onLocationChanged (Location location) 

È un'operazione molto semplice che consente di notificare i valori correnti di posizione attraverso il 
parametro di tipo Location, che incapsula diversi dati caratteristici appunto di una posizione come le 
coordinate di latitudine e longitudine, l'altitudine insieme ad altre come la velocità (speed) o 
l'accuratezza delle misure stesse. Per ascoltare le variazioni di posizione sarà quindi sufficiente creare 
un'implementazione di LocationListener ttl grado di utilizzare le informazioni che il sistema 
notificherà di volta in volta. 

Non tutte le applicazioni sono però uguali, nel senso che la stessa frequenza di ricezione degli 
eventi di location dipenderà dall'accuratezza richiesta. Per questo motivo le API a nostra disposizione 
ci permettono di configurare diversi parametri tra cui la frequenza degli update e la relativa precisione. 
Per impostare queste informazioni si può utilizzare un oggetto di tipo LocationRequest che poi 
useremo in fase di avvio del servizio. È un oggetto molto importante soprattutto al fine di ottenere una 
calibrazione ottimale tra accuratezza della misura e risorse utilizzate (soprattutto la batteria). In questo 
senso il metodo più importante è il seguente: 

public LocationRequest setlnterval (long millis) 

il quale permette di impostare quello che è l'intervallo desiderato per gli aggiornamenti. Si tratta 
infatti di un intervallo che il sistema cercherà di soddisfare per quanto possibile ma che non potrà mai 
garantire con certezza proprio per il fatto che la location, coni Play Services, è ora un'informazione 
condivisa con altre applicazioni Se non ci sono meccanismi per acquisire la posizione potremmo 
anche non ricevere mai alcuna notifica. All'opposto potremmo invece ricevere un numero maggiore di 
notifiche grazie alla configurazione di altre applicazioni che hanno impostato intervalli inferiori A 
questo proposito l'SDK ci consente di limitare il numero delle notifiche attraverso il metodo 

public LocationRequest setFastestlnterval (long millis) 

In pratica, il metodo setintervai o ci permette di impostare quella che è la frequenza da noi 
preferita in base alle caratteristiche della nostra applicazione, mentre il metodo 
setFastestlnterval o consente di impostare quello che sarà sicuramente l'intervallo minimo tra ima 
notifica e la successiva; si tratta in questo caso di un'impostazione certa. L'aspetto interessante 
nell'utilizzo del metodo setFastestlnterval o riguarda la possibilità di far dipendere la frequenza di 
aggiornamento della location dalle impostazioni delle altre applicazioni eventualmente installate. 

Il secondo grado di libertà prevede l'impostazione del livello di accuratezza attraverso il seguente 
metodo: 

public LocationRequest setPriority ( int priority) 

a cui possiamo passare uno dei valori rappresentati dalle seguenti costanti statiche della classe 

LocationRequest: 

• PRIORITY_HIGH_ACCURACY 

• P R I OR I T Y_B AL AN C E D_P OWE R_AC CURAC Y 

• PRIORITY_NO_POWER 

Queste rappresentano comunque delle richieste il cui soddisfacimento dipende da diversi fattori, tra 
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cui l'implementazione delle API nel dispositivo o la presenza o meno di meccanismi più o meno 
accurati di determinazione della location. In teoria, quindi, il valore priority_high_accuracy 
permette di richiedere al sistema di otterenere F informazione più accurata possibile tra quelle 
disponibili, per cui si fa spesso riferimento a una misura ottenuta da GPS (nel caso in cui sia attivato il 
permesso di posizione accurata). Il valore priori ty_balanced_power_accuracy descrive 
un'accuratezza di circa 100 metri, che potrebbe essere utilizzata anche con un permesso coarse, che 
rappresenta spesso un buon compromesso con un consumo ottimale della batteria. Infine il valore 
priority_no_power è molto curioso: consente di ottenere un'informazione di location senza alcun 
consumo di risorse. È il caso tipico in cui si ha un aggiornamento della location dovuto alle 
impostazioni ed esecuzione di un'altra applicazione di cui la nostra applicazione diventa quindi un 
listener passivo. 

Una volta configurata la xxx si può avviare il servizio di aggiornamento della location attraverso il 
metodo 

public void requestLocationUpdates (LocationRequest request, LocationListener listener) 

il quale potrà essere invocato solamente su un oggetto di tipo Locationciient nello stato 
connected. Un aspetto di fondamentale importanza riguarda il thread su cui viene chiamato il metodo 
di callback con le informazioni sulla location. Nel caso si utilizzasse il metodo precedente, il thread in 
questione sarà quello del chiamante. Se si volesse eseguire il metodo di callback in un thread separato 
si dovrà creare un looper nel modo visto nei capitoli precedenti e poi invocare il seguente overload 

del metodo requesLocationUpdates () : 

public void requestLocationUpdates (LocationRequest request, 

LocationListener listener, Looper looper) 

Nella nostra applicazione abbiamo avviato il servizio di update della location attraverso le seguenti 
poche righe di codice nel metodo di callback della nostra implementazione di LocationListener: 

final LocationRequest locationRequest = new LocationRequest () ; 
locationRequest . setlnterval (UPDATE_INTERVAL) ; 
locationRequest . setFastestlnterval (FASTEST_UPDATE_INTERVAL) ; 
locationRequest . setPriority (LocationRequest . 

PRIORI TY_BALANCED_POWER_ACCURACY) ; 
mLocationClient . requestLocationUpdates (locationRequest, mLocationListener ) ; 

Notiamo come sia stata creata un'istanza di LocationRequest inizializzata con le informazioni 
relative all'intervallo desiderato, a quello tollerato e a una priorità che ci permette di utilizzare le 
risorse in modo ragionevole. Abbiamo quindi utilizzato la nostra implementazione di 

LocationListener e l'oggetto LocationRequest COme parametri di lequestLocationUpdates ( ) . 

Tale implementazione è molto semplice e non fa altro che invocare il metodo showMapFragment o che 
consente l'aggiunta di una mappa, come descriveremo successivamente: 

private LocationListener mLocationListener = new LocationListener ( ) { 
gOverride 

public void onLocationChanged (Location location) { 
showMapFragment ( ) ; 

} 

}; 

Come possiamo vedere dal codice del progetto allegato, l'avvio dell' update della location avviene 
in corrispondenza del metodo di callback onstart ( ) a seguito di una connessione ai Google Play 
Services avvenuta con successo. Analogamente, in corrispondenza del metodo onstop ( ) dovremo 
provvedere a fermare l'aggiornamento attraverso l'utilizzo di questo metodo sempre del 

LocationClient: 
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public void removeLocationUpdates (LocationListener listener) 

a cui passiamo il riferimento al LocationListener registrato in precedenza. Ecco che il nostro 
metodo onStop ( ) diventa 
HOverride 

protected void onStopO { 

if (mLocationClient.isConnectedO ) { 

mLocationClient . removeLocationUpdates (mLocationListener ) ; 

} 

mLocationClient . disconnect ( ) ; 
super . onStop ( ) ; 

} 

Lasciamo al lettore la verifica, attraverso alcuni messaggi di log, di quanto detto in relazione alla 
frequenza di aggiornamento della location Sarà facile constatare come non vi sia una frequenza certa 
di aggiornamento, per cui dovremo sempre progettare le nostre applicazioni di conseguenza. 



Utilizzare le Google Maps 

A questo punto abbiamo visto come sia possibile ottenere la posizione corrente rappresentata da 
un oggetto di tipo Location. Quello che vogliamo ottenere ora è però la visualizzazione di una mappa 
che andremo poi a centrare con la posizione a nostra disposizione. Per farlo vogliamo utilizzare le 
ultime API, che sono anch'esse contenute nei Google Play Services e che corrispondono alle 
Google Maps Andro id API nella versione 2. 

NOTA 

Anche l'utilizzo delle Google Maps Android API presuppone l'inizializzazione dei servizi di Google 
Play che abbiamo già implementato per il reperimento della location. 

Prima di questo abbiamo però bisogno di ima fase di configurazione all'interno della Google API 
Console a cui possiamo accedere attraverso il link https://code.google.com/apis/console. 

Attraverso la relativa opzione nel menu a tendina sulla sinistra creiamo un progetto che chiamiamo 
WakeMe, come possiamo vedere nella Figura 14.6. 



Status Notes 



kRI 
PI 



Create project 

Enter the name for your project: 
WakeMej 



Create project 



Cancel 



ADI 



I 1 OFF 1 



Figura 14.6 Creazione di un progetto nella Google API Console. 

A questo punto, se non già selezionato, andiamo nella pagina relativa ai Services e cerchiamo la 
voce Google Maps Android API v2, che attiviamo come nella Figura 14.7 attraverso lo switch 
corrispondente. 
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1 i 

I Google Contacts CandDAV API 
C Google Maps Android API v2 
' Google Maps API v2 
' Google Maps API v3 



Keauesi access- 

O I Ioti 
u 



Courtesy limit: 10,000 requests/day 



O I [Off] 



OFF 



Courtesy limit: 25,000 requests/day • Pricing 
Courtesy limit: 25,000 requests/day • Pricing 



Figura 14.7 Attivazione del servizio di mappe in dispositivi Android. 

A questo punto selezioniamo la voce API Access e creiamo una nuova chiave da utilizzare nella 
nostra applicazione Android selezionando la voce Create new Android key, come possiamo vedere 
nella Figura 14.8. 



Create an OAuth 2.0 client ID... 



Simple API Access 

Use API keys to identify your project when you do not need to access user data. 



Key for browser apps (with referers) 




API key: 






Referers: 


Any referer allowed 




Activated on: 


Jun 18, 2013 4:10 ANI 




Activated by: 


■^►■^^^MBB*- you 





Create new Server key... Create new Browser key... Create new Android key... Create new iOS key.. 



Notification Endpoints 



Figura 14.8 Sezione di creazione delle chiavi di accesso ai servizi. 

Per poter eseguire questa azione abbiamo però bisogno della firma SHA-1 che utilizzeremo per 
firmare l'applicazione. Per il momento utilizziamo il certificato di debug che sappiamo essere 
contenuto nella cartella -/.android (o comunque nella cartella associata all'utente nel corrispondente 
sistema operativo). Andiamo quindi in questa cartella .android ed eseguiamo, da shell, il comando 

keytool -list -v -keystore debug . keystore -alias androiddebugkey -storepass android - 
keypass android 

ottenendo un risultato simile al seguente, che abbiamo leggermente offuscato inserendo delle xx. 

Alias name : androiddebugkey 
Creation date: 21-May-2013 
Entry type : PrivateKeyEntry 
Certificate ohain length: 1 
Certificate [ 1 ] : 

Owner: CN=Android Debug, 0=Android, C=US 
Issuer: CN=Android Debug, 0=Android, C=US 
Serial number : 3e705bb0 

Valid from: Tue May 21 10:32:13 BST 2013 untìl: Thu May 14 10:32:13 BST 2043 

Certificate f ingerprints : 

MD5 : XX: XX: XX: 65 :XX:XX: 57 :XX:XX:XX:B1 :XX:XX:XX:EC :E4 

SHA1 : 1B :XX: 2 7 :XX: 4F : XX : 3F :XX:F0 :XX:XX:EA: 54 :XX: 2E : XX: XX: XX: 9C :XX 

SHA25 6 : 

XX: 9F : XX: XX: XX: XX: XX: 51 :B1 :A8 : XX: XX: XX: XX: D2 : 1E : 39 : XX: XX: XX: XX: 67 : 31 : XX: XX: XX: AB : 93 : XX: XX: 
Signature algorithm name: SHA256withRSA 
Version: 3 

Nel caso del certificato di produzione dovremo eseguire lo stesso comando modificando il file con 
estensione . keystore e la password, che per debug è android. Il valore di interesse per noi è 
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comunque quello associato a SHA1, che andremo a utilizzare per la creazione della chiave di 
sicurezza come visualizzato nella Figura 14.9. 



Configure Android Key for WakeMe 

This key can be deployed in your Android applications. 

API requests are sent directly to Google from your clients' Android devices. Google verifies that 
each request originates from an Android application that matches one of the certificate SHA1 
fingerprints and package names listed below. You can discover the SHA1 fingerprint of your 
developer certificate using the following command: 

keytool -list -v -keystore mystore .keystore Leam more 

Accept requests from an Android application with one of the certificate fingerprints 
and package names listed below: 

1B:XX:27:XX:4F:XX:3F:XX:F0:XX:XX:EA:54 :XX:2E:XX:XX:XX: 9C:XX;co.uk.raassim 
ocarli . android. wakeme 



One SHA1 certificate fingerprint and package name (separated by a semicolon) per line. Example: 

45:B5:E4:6F:36:AD:0A:98:94:B4:02:66:2B:12:17:F2:56:26:A0:E0;com.example 



Create Cancel 



Figura 14.9 Creazione della chiave per applicazioni Android. 

Abbiamo inserito la chiave shai seguita dal package della nostra applicazione separato da un 
punto e virgola (;). Non ci resta che premere il pulsante Create e ottenere quindi una chiave del tipo 
di quella mostrata nella Figura 14. 10. 



Simple API Access 

Use API keys to identify your project when you do not need to access user data. Learn more 



Key for Android apps (with certificatesi 

API key: AIzaSy^H^^H^^^M^B^^^f 8QhsWUuc 

Android apps: ^I^^^H^^^^B: 3F:4^gg^H^H^MM.C : 2E : 3E^^Bft: 9C : E6; co . uk.massimocarli . and 
roid.wakeme 

Activated on: Jun 18, 2013 4:39 AM 
Activated by: ^PMM^f - you 



Figura 14.10 Le informazioni per l'accesso alle mappe dalla nostra applicazione Android. 

Il valore che utilizzeremo nell'applicazione è quello relativo all' API Key che andiamo a utilizzare nel 
file AndroidManifest .xml della nostra applicazione, con una definizione del seguente tipo all'interno 
dell'elemento <appiication/> sostituendo la stringa api_key con il valore sopra indicato: 

<meta-data android : name="com . google . android . maps . v2 . API_KEY" android : value="API_KEY" /> 
ATTENZIONE 

È bene sottolineare che una mancata visualizzazione della mappa conoide spesso con un'errata 
definizione della chiave. In questi casi si consiglia di ripetere il procedimento descritto. 

L'accesso ai servizi delle mappe necessita inoltre di alcuni permessi che definiamo sempre nel 
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nostro file di configurazione, e precisamente: 

<uses-permissionandroid: name="android . permission . INTERNET" /> 
<uses-permissionandroid : name=" android . permission . ACCE SS_NETWORK_S TATE " / > 
<uses-permissionandroid : name=" android . permission . WRITE_EXTERNAL_STORAGE " /> 
<uses-permission 

android: name="com. google . android . provide rs . gsf .permission . READ_GSERVICES" / > 

L'applicazione potrebbe richiedere altri permessi in base a quelle che sono le sue operazioni 
sensibili. Quelli elencati sono comunque permessi che non si direbbero richiesti per la visualizzazione 
di una mappa, per cui ne diamo breve giustificazione. Il permesso android. permission. internet 
serve per permettere l'accesso alla rete e quindi per eseguire il download dei tile che compongono le 
mappe. 

NOTA 

Un tile (mattonella) è una parte della mappa le cui dimensioni dipendono dal livello di zoom e che 
viene scaricato dalla Rete in base alle esigenze. 

In caso contrario non ci sarebbe alcuna possibilità da parte di Android di scaricare le informazioni 
a meno di non averle già tutte in memoria locale. Anche il permesso 

android. permission. access_network_state è utilizzato dalle mappe per sapere se è possibile o 
meno eseguire il download dei tile precedenti o riprenderlo qualora ritornasse una connessione prima 
assente. Le mappe, al fine di ridurre l'utilizzo della rete, hanno la necessità di creare una cache sul file 
system delle immagini relative ai tile. Per questo motivo dobbiamo definire anche l'utilizzo del 
permesso android. permission. write_external_storage. Infine, per l'accesso ai web service di 
Google è stato definito un permesso personalizzato associato alla costante 

com. google . android. providers . gsf . permission . READ_GSERVICES. A questo punto manca ancora 

un ultimo sforzo legato al fatto che le mappe utilizzano le OpenGLES nella versione 2. Questa 
definizione serve solamente per impedire il download dell'applicazione dallo store a quei dispositivi 
che non supportano tali librerie. Aggiungiamo quindi la definizione 

<uses-f eature android : glEsVersion=" 0x00020000" android: required="true" / > 

Siamo così pronti a inserire la mappa all'interno della nostra UI attraverso il seguente metodo, che 
invochiamo quando la location (ottenuta inizialmente oppure ottenuta da un update) è disponibile: 

private void showMapFragment ( ) { 

Fragment existingMapFragment = getSupportFragmentManager ( ) 

. f indFragmentByTag (MAP_FRAGMENT_TAG) ; 
if (existingMapFragment == nuli && mCurrentLocation != nuli) { 

// Creiamo MapFragment per mostrare la posizione sulla mappa 
SupportMapFragment mapFragment = SupportMapFragment . newlnstance ( ) ; 
FragmentTransaction f ragmentTransaction = 

getSupportFragmentManager ( ) . beginTransaction ( ) ; 
f ragmentTransaction . add (R. id . anchor_point , mapFragment, 

MAP_FRAGMENT_TAG) ; 
f ragmentTransaction . oommit () ; 
// Prendiamo l'oggetto mGoogleMap 
mGoogleMap = mapFragment . getMap ( ) ; 
} else { 

// Prendiamo l'oggetto mGoogleMap dall'oggetto esistente 
mGoogleMap = ((SupportMapFragment) existingMapFragment) . getMap () ; 




Per la gestione della rotazione del dispositivo è importante verificare che il MapFragment non sia già 
stato aggiunto prima. E sufficiente cercare il fragment utilizzando il suo tag. Nel caso in cui il valore 
fosse nuli dovremo inserire il fragment nel modo ormai noto. Facciamo qui notare l'utilizzo della 
classe SupportMapFragment invece di MapFragment per il semplice motivo che dobbiamo supportare 
anche le versioni precedenti a un API Leveldi 12. L'oggetto che utilizziamo per l'accesso ai servizi 
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della Map è di tipo GoogieMap e si ottiene appunto dal fragment precedente. Vediamo come si ottenga 
il riferimento all'oggetto dal fragment nei due casi in cui il primo sia già stato aggiunto al layout oppure 
no. 

Il passo successivo consiste nelT impostare un tipo di mappa utilizzando dei Settings che abbiamo 
implementato nel modo standard come visto nel Capitolo 8. 
Abbiamo aggiunto le righe di codice evidenziate alla fine del metodo precedente: 

private void showMapFragment ( ) { 

Fragment existingMapFragment = getSupportFragmentManager ( ) 

. f indFragmentByTag (MAP_FRAGMENT_TAG) ; 
if (existingMapFragment == nuli && mCurrentLocation != nuli) { 

// Creiamo MapFragment per mostrare la posizione sulla mappa 
SupportMapFragment mapFragment = SupportMapFragment . newlnstance () ; 
FragmentTransaction f ragmentTransactìon = 

getSupportFragmentManager ( ) . beginTransaction ( ) ; 
fragment Trans action . add (R. id . anchor_point , mapFragment, 

MAP_FRAGMENT_TAG) ; 
f ragmentTransaction . oommit () ; 
// Prendiamo l'oggetto mGoogleMap 
mGoogleMap = mapFragment . getMap () ; 
} else { 

// Prendiamo mGoogleMap dall'oggetto esistente 

mGoogleMap = ((SupportMapFragment) existingMapFragment ). getMap () ; 

} 

String mapTypePrefs = Pref erenceManager 

. getDef aultSharedPref erences (this) 

. getString (Conf . SettingKeys . MAP_TYPE_KEY, nuli) ; 
int mapType = WakeMeUtility.getGoogleMapTypeFromResourceValue (this, 

mapTypePrefs) ; 
mGoogleMap . setMapType (mapType) ; 

} 

In sostanza non facciamo altro che andare a vedere il valore relativo al tipo di mappa nelle 
Pref erences impostandolo quindi sull'oggetto di tipo GoogieMap attraverso il suo metodo 

public final void setMapType (int type) 

Il metodo WakeMeUtility . getGoogleMapTypeFromResourceValue ( ) è Semplicemente una utility che 

ci permette di convertire la String memorizzata nei Settings nella corrispondente costante della classe 

GoogleMap. 

A questo punto, se il lettore eseguisse il codice di cui sopra otterrebbe quasi certamente una 
NuiiPointerException dovuta al fatto che la variabile mGoogleMap è nuli. Questo perché il fragment 
non crea l'istanza relativa istanza fino a che non viene eseguito il suo metodo oncreatevìew ( ) , ovvero 
al termine della transazione all'interno della quale lo stesso fragment viene aggiunto all'activity. 
Un'alternativa sarebbe quella di non gestire l'aggiunta del fragment attraverso del codice ma 
utilizzando iltag <fragment/> nel layout. La seconda opzione, che invece abbiamo implementato, 
implica la realizzazione di una specializzazione della classe SupportMapFragment che notifica alla 
propria activity l'esecuzione del proprio metodo onCreateView 0 passando il riferimento dell'oggetto 
GoogleMap. Questo avviene se l' activity implementa un'interfaccia di callback del tipo di quelle che 
abbiamo ormai imparato a gestire nel Capitolo 4. Abbiamo quindi creato questa classe: 

public class CallbackMapFragment extends SupportMapFragment { 
public interface OnGoogleMapReadyListener { 
void mapIsReady (GoogleMap googleMap) ; 

} 

private OnGoogleMapReadyListener mOnGoogleMapReadyLìstener; 
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SOverride 

public void onAttach (Activity activity) { 
super . onAttach (activity) ; 

if (activity instanceof OnGoogleMapReadyListener) { 

mOnGoogleMapReadyListener = (OnGoogleMapReadyListener) activity; 

} 

} 

@Override 

public View onCreateView (Layoutlnf later inflater, ViewGroup container, 

Bundle savedlnstanceState) { 
View superView = super . onCreateView (inflater, container, 

savedlnstanceState) ; 
//La view è pronta, quindi notifichiamo se necessario 
if (mOnGoogleMapReadyListener != nuli) { 

mOnGoogleMapReadyListener .mapIsReady (getMapO ) ; 

} 

// Torniamo alla view precedente 
return superView; 

} 

} 

che abbiamo utilizzato nella nostra activity principale nel seguente modo (abbiamo riportato solo le 
modifiche): 

public class MainActivity extends FragmentActivity 

implements CallbackMapFragment . OnGoogleMapReadyListener { 

/ / Come prima . . . 

private void showMapFragment ( ) { 

Fragment existingMapFragment = 

getSupportFragmentManager () . f indFragmentByTag (MAP_FRAGMENT_TAG) ; 
if (existingMapFragment == nuli && mCurrentLocation != nuli) { 

// Creiamo MapFragment per mostrare la posizione sulla mappa 
SupportMapFragment mapFragment = new CallbackMapFragment () ; 
FragmentTransaction f ragmentTransaction = 

getSupportFragmentManager ( ) . beginTransaction ( ) ; 
f ragmentTransaction . add (R . id. anchor_point , mapFragment , 

MAP_FRAGMENT_TAG) ; 
f ragmentTransaction . commìt ( ) ; 
} else { 

// Prendiamo mGoogleMap dall'oggetto esistente 

mGoogleMap = ((SupportMapFragment) existingMapFragment ). getMap () ; 
// Impostiamo il tipo di mappa 
synchMapType ( ) ; 

} 

} 

gOverride 

public void mapIsReady (final GoogleMap googleMap) { 
// Salviamo la GoogleMap reference 
mGoogleMap = googleMap; 
// Impostiamo il tipo di mappa 
synchMapType ( ) ; 

} 



private void synchMapType ( ) { 

// Leggiamo il tipo di mappa nelle preferenze e impostiamomelo per Map 

String mapTypePrefs = PreferenceManager 
. getDefaultSharedPreferences (this) 
. getString (Conf . SettingKeys .MAP_TYPE_KEY, nuli) ; 

int mapType = WakeMeUtility . getGoogleMapTypeFromResourceValue (this, 
mapTypePrefs) ; 

mGoogleMap. setMapType (mapType) ; 

} 
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} 

Nel caso in cui l'attività venisse creata, avendo implementato l'interfaccia dicallback, riceveremmo 
il riferimento all'oggetto di tipo GoogieMap attraverso il metodo lapisReady o . Noi abbiamo creato il 
metodo di utilità di nome synchMapType ( ) in quanto abbiamo bisogno di richiamarlo da due punti 
diversi a seconda che l'oggetto GoogieMap sia già disponibile oppure no. 

Il tipo di mappa da visualizzare non è l'unica configurazione possibile sulla mappa. Possiamo infatti 
specificare anche: 

• lo stato iniziale, inteso come location, livello di zoom e quelli che si chiamano hearing e tilt; 

• se i controlli di zoom sono visibili oppure no; 

• quali particolari gesti abilitare per l'utente. 

Per vedere come utilizzare queste funzioni nella nostra applicazione, diamo una breve ma 
importante definizione nel paragrafo successivo. 

Possibili configurazioni di una GoogleMap 

Abbiamo già visto come una prima configurazione riguardi il tipo di mappa disponibile, che può 
essere di uno dei seguenti tipi; 

• None 

• Normal 

• Hybrid 

• Satellite 

• Terrain 

a ciascuno dei quali corrisponde sia una costante della classe GoogleMap sia un attributo 
dell'elemento <fragment/>. In questa fase tratteremo i possibili valori come concetti rimandando alla 
documentazione per i valori reali delle costanti in Java o degli attributi nel documento XML di layout 
di cui daremo un esempio successivamente. Nel caso della nostra applicazione abbiamo gestito il tipo 
di mappa definendo delle risorse di tipo array come segue: 

<string name="pref_map_type_normal">Normal</string> 
<string name="pref_map_type_hybrid">Hybrid</string> 
<string name="pref_map_type_satellite">Satellite</ string> 
<string name="pref_map_type_terrain">Terrain</string> 
<string name="pref_map_type_none">None</ string> 

<string-array name="pref_map_types "> 

<item>@string/pref_map_type_normal</ìtem> 

<item>@strìng/ pref_map_type_hybrid</item> 

<item>@string/ pref_map_type_satellite</ item> 

<item>@string/pref_map_type_terrain</ item> 

<item>@string/pref_map_type_none</ item> 
</ string-array> 

<string-array name="pref_map_type_values "> 

<item>@string/ pref_map_type_normal</item> 

<item>@string/pref_map_type_hybrid</item> 

<item>@string/ pref_map_type_satellite</ item> 

<item>@string/ pref_map_type_terrain</ item> 

<item>@string/pref_map_type_none</ item> 
</string-array> 

impostando poi un metodo di utilità per la conversione con le costanti di GoogleMap del seguente 
tipo: 

public static int getGoogleMapTypeFromResourceValue (final Context context, 
final String resourceValue) { 
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final Resources resouroes = context . getResources ( ) ; 

String currentValue = resources . getString (R . string . pref_map_type_normal) ; 
if (currentValue . equals (resouroeValue) ) { 
return GoogleMap . MAP_TYPE_NORMAL ; 

} 

currentValue = resources . getString (R . string .pref_map_type_hybrid) ; 
if (currentValue . equals ( resouroeValue) ) { 
return GoogleMap . MAP_TYPE_HYBRID ; 

} 

currentValue = resources . getString (R . string . pref_map_type_satellite) ; 
if (currentValue . equals (resouroeValue) ) { 
return GoogleMap. MAP_TYPE_SATELLITE; 

} 

currentValue = resources . getString (R . string .pref_map_type_terrain) ; 
if (currentValue . equals (resouroeValue) ) { 
return GoogleMap . MAP_TYPE_TERRAIN ; 

} 

currentValue = resources . getString (R . string .pref_map_type_none) ; 
if (currentValue . equals ( resourceValue) ) { 
return GoogleMap . MAP_TYPE_NONE ; 

} 

// In questo caso ritorniamo il normale 
return GoogleMap . MAP_TYPE_NORMAL ; 

} 

Indipendentemente dal tipo, la mappa viene visualizzata come se vi fosse ima videocamera 
inizialmente in posizione verticale rivolta verso il basso. La Terra è ovviamente (approssimativamente) 
sferica, ma le mappe vengono visualizzate utilizzando una proiezione chiamata mercator projection 
che ne permette la visualizzazione su un piano. Gli strumenti che descriveremo permettono la modifica 
della posizione della videocamera con conseguente modifica di quanto visualizzato. 

La prima di queste informazioni riguarda la posizione della camera in termini di latitudine e 
longitudine. Si tratta della prima informazione che abbiamo ottenuto attraverso l'oggetto 
Locatìonciient che ora vogliamo utilizzare per centrare la mappa. Per questo tipo di operazioni le 
API prevedono l'utilizzo di quello che si chiama cameraupdate, di cui è possibile ottenere delle istanze 
diverse attraverso la classe Carne raUpdateFact or y. Come vedremo questa classe ci permetterà di 
modificare ciò che è visibile nella mappa anche attraverso un'animazione. Nel caso specifico del 
centrare la mappa in una particolare posizione, si possono utilizzare queste istruzioni: 

private void centerHere ( final Location currentLocation) { 
if (currentLocation == nuli) { 

// Posizione al momento non disponibile 
return; 

} 

/ / Prendiamo 1 ' oggetto LatLng dall ' oggetto Location 

final LatLng currentLatLng = new LatLng (currentLocation . getLatitude () , 

currentLocation. getLongitude () ) ; 
// Prendiamo CameraUpdate dalla posizione data 
CameraUpdate positionUpdate = 

CameraUpdateFactory . newLatLng (currentLatLng) ; 
// Utilizziamo CameraUpdate per centrare la mappa 
mGoogleMap.moveCamera (positionUpdate) ; 

} 

Come abbiamo già visto, la location potrebbe non essere subito disponibile, per cui facciamo un 
controllo che ci consente di evitare una NuiiPointerException. 

NOTA 

Questo non è un problema in quanto da un lato invocheremo questo metodo solo quando la location 
è disponibile attraverso la selezione di un pulsante sulla barra delle azioni o di un'opzione, oppure lo 
invocheremo quando decideremo di ascoltare gli aggiornamenti di posizione. 

Se la location è disponibile, creiamo un oggetto di tipo LatLng che incapsula le informazioni di 
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latitudine e longitudine, per poi passarlo come parametro del metodo statico di Factory 

CameraUpdateFactory .newLatLng () per Ottenere l'oggetto CameraUpdate che poi applicheremo alla 
GoogleMap attraverso il SUO metodo moveCameral). Ilmetodo CameraUpdateFactory. newLatLng () ha 

un unico parametro di tipo LatLng e quindi permette di modificare solo quell'informazione. Ne esiste 
comunque anche un overload che prevede come secondo parametro anche il livello di zoom per 
modificare le due informazioni contemporaneamente. In questi casi è buona norma sfruttare la 
possibilità di aggiungere un'animazione. È sufficiente modificare il precedente metodo nel seguente 
modo: 

private void centerHere ( final Location currentLocation, 
final boolean animated) { 
if (currentLocation == nuli) { 

// Posizione al momento non disponibile 
return; 

} 

/ / Prendiamo 1 ' oggetto LatLng dall 1 oggetto Location 

final LatLng currentLatLng = new LatLng (currentLocation. getLatitude () , 

currentLocation. getLongitude () ) ; 
/ / Prendiamo CameraUpdate dalla posizione data 
CameraUpdate positionUpdate = CameraUpdateFactory 

.newLatLng (currentLatLng) ; 
if (animated) { 

// Con l'animazione 

mGoogleMap . animateCamera (positionUpdate) ; 
} else { 

// Utilizziamo CameraUpdate per centrare la mappa 
mGoogleMap .moveCamera (positionUpdate) ; 

} 

} 

dove vediamo l'aggiunta del parametro che ci consente di decidere se utilizzare l'animazione 
oppure no. Nel nostro caso abbiamo creato una voce nei Settings per abilitare o meno le animazioni 
e decidere quale valore assegnare al parametro animated. Per ilmetodo movecamerao esistono altri 
due overload che permettono di ricevere notifica della cancellazione o del completamento 
dell'operazione attraverso l'interfaccia GoogleMap. canceiabiecaiiback, oltre che la corrispondente 
durata. Per questo motivo abbiamo modificato nuovamente il metodo precedente come segue: 

private void centerHere ( final Location currentLocation, 
final boolean animated) { 
if (currentLocation == nuli) { 

// Posizione al momento non disponibile 
return; 

} 

// Prendiamo l'oggetto LatLng dall'oggetto Location 

final LatLng currentLatLng = new LatLng (currentLocation . getLatitude () , 

currentLocation . getLongitude () ) ; 
// Prendiamo CameraUpdate dalla posizione data 
CameraUpdate positionUpdate = CameraUpdateFactory 

.newLatLng (currentLatLng) ; 
if (animated) { 

// Con l'animazione 

mGoogleMap . animateCamera (positionUpdate, 

Conf.MAP_ANIMA.TION_DURA.TION, 
new GoogleMap . CancelableCallback ( ) { 

@Override 

public void onFinish() { 

Log . d ( TAG_LOG , "Map Animation Finished") ; 

} 

@Override 

public void onCancel ( ) { 
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Log.d(TAG_LOG, "Map Animation Canceled") ; 

} 

}); 
} else { 

// Utilizziamo CameraUpdate per centrare la mappa 
mGoogleMap .moveCamera (positionUpdate) ; 

} 

} 

Oltre alla posizione possiamo modificare quello che è il livello di zoom della mappa, il quale viene 
rappresentato da un valore di tipo f ioat compreso tra O.Of e un altro valore che dipende dal tipo di 
mappa, dalle dimensione del display e dalla zona visualizzata. Maggiore è il valore di zoom, maggiore 
è il dettaglio. Aggiungere 1 .0 allo zoom corrente è uguale a dividere per 2 la zona visualizzata sullo 
schermo. Anche per lo zoom si ottiene il riferimento a un oggetto CameraUpdate, che quindi si 
sottomette alla GoogieMap nel modo già visto. Qui i metodi che ci permettono di ottenere la modifica 
di 1 .0 del livello di zoom corrente lasciando le altre proprietà immutate sono questi: 

public static CameraUpdate zoomino ; 
public static CameraUpdate zoomOutO; 

Qualora volessimo impostare un valore di zoom specifico sarebbe sufficiente utilizzare il seguente 
metodo: 

public static CameraUpdate zoomTo(float zoom); 

Nel caso di una variazione di zoom diversa da 1 .0 possiamo infine utilizzare il metodo: 

public static CameraUpdate zoomBy(float amount); 

In questo caso esiste anche il seguente overload 

public static CameraUpdate zoomBy ( f loat amount, Point focus); 

il quale permette di eseguire l'operazione di zoom relativo indicando anche quale deve essere il 
punto della mappa che rimane fermo. Di default il focus è il punto centrale della mappa. Se il lettore 
eseguisse l'applicazione per come è a questo punto, otterrebbe il risultato della Figura 14.11, conia 
mappa centrata nella propria location 
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Figura 14.11 Mappa centrata nella location corrente. 



Come possiamo vedere la mappa viene visualizzata con il centro nella location corrente e vengono 
messi a disposizione dell' utente i classici pulsanti per le operazioni di zoom Vedremo dopo come 
eventualmente toglierli; per il momento ci chiediamo come si può avere un dettaglio maggiore e 
utilizzare un livello di zoom più elevato fin dall'inizio. Da quanto visto, basterebbe creare un nuovo 
cameraupdate e quindi applicarlo dopo aver impostato quello relativo alla posizione. Fortunatamente 
le API ci offrono un metodo unico per eseguire le due operazioni, ovvero 

public static CameraUpdate newLatLngZoom (LatLng latLng, fiat zoom) 

che andiamo a utilizzare impostando come valore iniziale di zoom uno che abbiamo definito in 
un'opportuna costante che abbiamo impostato a 12 (i valori accettati vanno da 2 a 21). Nel codice 
del precedente metodo l'istruzione 

CameraUpdate positionUpdate = CameraUpdateFactory . newLatLng (currentLatLng) ; 

viene sostituita da 

CameraUpdate positionUpdate = CameraUpdateFactory . newLatLngZoom (currentLatLng, 

Conf . START_ZOOM_LEVEL) ; 

ottenendo il risultato della Figura 14.12. 
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Figura 14.12 Mappa centrata nella location corrente con un valore di zoom pari a 12. 

Prima di proseguire, facciamo notare anche la presenza del seguente metodo, che all'apparenza 
poteva sembrare il più ovvio e che permette di spostare la mappa di una quantità in pixel nelle due 
direzioni x e y. Questo in realtà non è banale in quanto l'efièttiva traslazione dipende anche dallo 
zoom impostato. Il metodo da utilizzare per la creazione dell'oggetto cameraupdate è 

public static CameraUpdate scrollBy ( f loat xPixel, float yPixel) 

e il meccanismo di utilizzo del cameraupdate è lo stesso descritto sopra. 

Finora abbiamo visto come centrare la mappa in una data posizione utilizzando un dato livello di 
zoom Questo ha come conseguenza la visualizzazione di ima zona con una particolare estensione. 
Maggiore è il livello di zoom, minore sarà l'estensione della zona visualizzata ma con un dettaglio 
migliore. Spesso però abbiamo l'esigenza inversa, ovvero quella di disporre di un certo numero di 
punti e di volerli visualizzare tutti all'interno di ima mappa. In questo caso la posizione e il livello di 
zoom sono il risultato. Con le API a disposizione questa è un'operazione molto semplice e consiste 
nella creazione di un oggetto di tipo LatLngBounds da cui ottenere ancora l'oggetto di tipo 
cameraupdate da dare "in pasto" alla classe GoogieMap nel modo ormai consueto. Un esempio è dato 
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da questo metodo: 

private void showItalyO { 

// Definisce la posizione per città italiane 
final LatLng trieste = new LatLng (45 . 649535, 13.777972); 
final LatLng palermo = new LatLng (38 . 115688, 13.361267); 
// Creiamo LatLngBounds 

LatLngBounds latLngBounds = new LatLngBounds (palermo, trieste) ; 
// Prendiamo CameraUpdate per mostrare quei confini 
CameraUpdate boundsCameraUpdate = 

CameraUpdateFactory . newLatLngBounds (latLngBounds , 

Conf . BOUNDS_P ADDING) ; 
// Ci spostiamo lì 

mGoogleMap .moveCamera (boundsCameraUpdate) ; 

} 

È importante tare attenzione ai due punti che si utilizzano per la creazione dell'oggetto 
LatLngBounds: il primo parametro deve essere a sud-ovest, mentre il secondo a nord-est della zona 
che intendiamo visualizzare. In caso contrario otterremmo un' eccezione. Il secondo parametro 
descrive invece la larghezza in pixel del bordo attorno al rettangolo che comprende i due punti 
specificati nel costruttore. Se questo valore fosse 0, le due coordinate verrebbero visualizzate sui 
bordi e quindi non in modo leggibile. Nel nostro caso abbiamo definito ima costante di valore 100 
ottenendo il risultato nella Figura 14.13. 
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Figura 14.13 Visualizzazione di Palermo e Trieste nella stessa mappa. 



In relazione a questa funzionalità esiste anche il metodo 

public static CameraUpdate newLatLngBounds (LatLngBounds bounds, int width, 
int height, int padding) ; 

il quale consente di specificare anche la dimensione in pixel del rettangolo all'interno del quale 
visualizzare i due punti specificati In sintesi è come se lo spazio disponibile in cui visualizzare la 
regione con i due punti fosse quella delle dimensioni specificate e centrata nella mappa. 

Finora abbiamo visto come muoversi sulla mappa, in modo animato oppure no, attraverso diversi 
metodi di Factory in grado di fornirci l'istanza di CameraUpdate opportuna. Qualora volessimo 
impostare in modo veloce più informazioni potremmo utilizzare la classe cameraPosition. Qui non lo 
faremo, ma diciamo che è comunque possibile utilizzare istruzioni del tipo: 

final static LatLng ROVIGO = new LatLng (45 . 649535, 13.777972); 

CameraPosition cameraPosition = new CameraPosition . Builder ( ) 

. target (ROVIGO) // Imposta il centro della mappa su Rovigo 

.zoom(17) // Imposta lo zoom 

.bearing(90) // Imposta l'orientamento della camera verso est 

.tilt (30) // Imposta l'inclinazione della camera a 30° 

.build(); // Crea CameraPosition a partire dal Builder 

map . animateCamera (CameraUpdateFactory . newCameraPositìon (cameraPosition) ) ; 

Attraverso un cameraPosition . Builder ( ) si può indicare come punto centrale quello definito 
attraverso un oggetto di tipo LatLng e quindi il livello di zoom, di hearing e tilt. Non entriamo nel 
dettaglio di queste due ultime informazioni per le quali si rimanda alla documentazione ufficiale. 
Cercando di descriverli in modo intuitivo, diciamo solamente che il hearing rappresenta la rotazione 
del nord della mappa che si sta osservando. Possiamo pensare a questo concetto ricordando cosa 
succede quando si percorre una strada con un navigatore, lì tilt consente invece di gestire 
l'inclinazione con cui si osserva la mappa. In posizione normale la camera è perpendicolare al suolo. Il 
tilt ci permette di abbassarci e di osservare la mappa come se vi stessimo volando sopra. 

Concludiamo il paragrafo con un esempio di come definire un fragment relativo a una mappa 
direttamente in un documento XML di layout: 

<f ragment xmlns : android="http : / / schemas . android . com/apk/ res/androìd" 
xmlns :map="http : / / schemas . android . com/ apk/res-auto" 
android: ìd="@+id/map" 
android: layout_width="match__parent " 
android : layout_height="match__parent " 

class="com. google . android . gms .maps . Suppo rtMapF ragment " 

map: cameraBearing="112 . 5" 

map: cameraTargetLat="-33 .796923" 

map: cameraTargetLng="150 . 922 433" 

map : cameraTilt=" 30 " 

map : cameraZoom=" 13 " 

map : mapType= " norma 1 " 

map : uiCompass=" false " 

map : uiRotateGestures="true" 

map : uiScrollGestures=" f al se" 

map: uiTìltGestures="true" 

map : uiZoomControls=" false" 

map : uiZoomGestures="true" /> 

Si tratta semplicemente di specificare una serie di attributi che notiamo essere associati a un nuovo 
namespace relativo alla gestione della mappa. Per il significato dei vari attributi, peraltro ora evidente, 
si rimanda alla documentazione ufficiale. 
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Inseriamo dei marker sulla mappa 

Nei paragrafi precedenti abbiamo imparato a determinare la nostra posizione e a gestire la 
visualizzazione di ima Google Map. 
NOTA 

Un aspetto nuovo che forse non è stato dovutamente sottolineato riguarda la possibilità, grazie 
all'utilizzo del nuovo MapFragment (e supportMapFragment), di avere più mappe all'interno della stessa 
schermata; cosa prima non possibile e vincolata al solo utilizzo di una MapActivity. 

Come sappiamo le Google Maps sono degli strumenti molto importanti soprattutto nell'ottica di 
una loro personalizzazione. La prima possibilità consiste nell'aggiunta di quelli che si chiamano 
marker, i quali non sono altro che dei segnaposto sulla mappa che possiamo personalizzare in modi 
diversi: 

• modificando il colore dei pin standard; 

• personalizzando le icone; 

• aggiungendo un anchor point. 

Dal punto divista dello sviluppo, ogni marker è rappresentato da un'istanza della classe Marker 
che si può aggiungere alla mappa attraverso il seguente metodo della classe GoogieMap: 

public final Marker addMarker (MarkerOptions optìons) 

E un metodo che prevede un parametro di tipo MarkerOptions, che contiene tutte le informazioni 
del marker di cui otteniamo un riferimento come risultato dell'invocazione. Se andiamo a osservare la 
documentazione della classe MarkerOptions vediamo come sia una sorta di builder che, attraverso il 
meccanismo di chaining, ci consente di specificare le caratteristiche del marker e precisamente: 

• la posizione; 

• il poterlo spostare; 

• un titolo; 

• uno snippet; 

• la visibilità; 

• F anchor point; 

• l'icona. 

Per poter essere visualizzato sulla mappa, ogni marker deve avere necessariamente una posizione, 
la quale viene espressa attraverso un oggetto di tipo Lating, visto in precedenza, che può essere 
impostato attraverso il metodo 

public MarkerOptions position (LatLng position) 

E importante sottolineare come questa sia l'unica informazione obbligatoria, mentre le successive 
sono opzionali e possono quindi non essere utilizzate. Sebbene obbligatoria è comunque una 
caratteristica del marker che può cambiare impostando lo stesso come abilitato allo spostamento 
(drag-and-drop). Ogni marker di default non può essere spostato a meno che non si abiliti questa 
opzione attraverso il seguente metodo: 

public MarkerOptions draggable (boolean draggable) 

passando un valore true del parametro. L'evento che permetterà di spostare un marker sarà quello 
del long click, come verificheremo successivamente, mentre il semplice clic permette di visualizzare, 
di default, un titolo che è possibile personalizzare attraverso questo metodo: 

public MarkerOptions title (String title) 
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Si tratta dell'informazione che viene visualizzata sopra il marker nel momento in cui lo stesso viene 
selezionato. Nel caso in cui il titolo non fosse sufficiente, si può aggiungere del testo attraverso quello 
che si chiama snippet e che possiamo impostare con il metodo 

public MarkerOptions snippet (String snippet) 

Quando impostato, è quindi un testo che viene visualizzato al di sotto dell'eventuale titolo nel 
momento di selezione del marker con un clic. 

La proprietà che abbiamo chiamato visibilità non è altro che lo strumento da utilizzare se avessimo 
bisogno di rendere visibile o nascondere un particolare marker. Per farlo è possibile utilizzare il 
metodo: 

public MarkerOptions vìsible (boolean visible) 

Un altro concetto molto importante è quello di anchor point, che può essere impostato attraverso 
l'uso del seguente metodo sempre della classe MarkerOptions! 

public MarkerOptions anchor (float u, float v) 

Per capirne l'utilizzo iniziamo a scrivere alcune righe di codice per la semplice visualizzazione di un 
marker nella posizione corrente ottenuta con il meccanismo descritto nel paragrafo precedente. In 
particolare, nel metodo showMapFragment o della classe MainActìvìty abbiamo aggiunto le righe di 
codice evidenziate di seguito: 

private void showMapFragment ( ) { 

Fragment existingMapFragment = 

getSupportFragmentManager () . f indFragmentByTag (MAP_FRAGMENT_TAG) ; 
if (existingMapFragment == nuli && mCurrentLocation != nuli) { 

// Creiamo MapFragment per mostrare la posizione sulla mappa 
SupportMapFragment mapFragment = new CallbackMapFragment ( ) ; 
FragmentTransaction f ragmentTransactìon = 

getSupportFragmentManager ( ) . beginTransaction ( ) ; 
fragment Trans action . add (R. id . anchor_point , mapFragment, 

MAP_FRAGMENT_TAG) ; 
f ragmentTransaction . commit () ; 
} else { 

// Prendiamo mGoogleMap dall'oggetto esìstente 

mGoogleMap = ((SupportMapFragment) existingMapFragment ). getMap () ; 
//mGoogleMap . setMyLocationEnabled (true) ; 

// Impostiamo il tipo di mappa 
synchMapType () ; 

// Creiamo e aggiungiamo il marker 

final LatLng newLatLng = new LatLng (mCurrentLocation . getLatitude () , 

mCurrentLocation . getLongitude ( ) ) ; 
if (mHereMarker == nuli) { 

final MarkerOptions markerOptions = new MarkerOptions () ; 

markerOptions .position (newLatLng) ; 

mHereMarker = mGoogleMap . addMarker (markerOptions) ; 
} else { 

mHereMarker . setPosition (newLatLng) ; 

} 

} 

} 

Notiamo come, dopo aver ottenuto il riferimento all'oggetto di tipo GoogieMap, sia stato creato un 
oggetto di tipo LatLng che poi è stato utilizzato per creare il marker la prima volta e per modificarne 
la posizione tutte le volte successive. Le coordinate utilizzate sono quelle relative alla posizione 
corrente. Il codice precedente porta al risultato nella Figura 14.14. 
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Figura 14.14 Visualizzazione di un marker semplice nella posizione corrente. 

Più avanti vedremo come personalizzare il colore dell'icona standard oppure come sostituirla con 
un' immagine personalizzata. Per il momento vogliamo invece vedere qualè l'effetto di quello che 
abbiamo chiamato anchor point; per spiegarlo abbiamo bisogno di visualizzare la posizione corrente 
attraverso un pallino che si può abilitare attraverso questo metodo della classe GoogieMap 

public final void setMyLocationEnabled (boolean enabled) 

che avevamo commentato nel codice precedente. Passando un valore true come parametro si 
ottiene quello nella Figura 14.15, ovvero la visualizzazione di impallino proprio sotto l'icona del 
marker. 
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Figura 14.15 II pallino indica che abbiamo abilitato la visualizzazione della posizione corrente 
nella mappa. 

A questo punto supponiamo che l'icona utilizzata per un marker abbia dimensioni W x H che 
immaginiamo di forma rettangolare. Nella Figura 14.15 abbiamo un'icona che è più alta che larga e 
viene visualizzata al di sopra della posizione corrente e centrata orizzontalmente. Per l'impostazione 
dell' anchor point dobbiamo comunque pensare che si tratti di un'icona di dimensioni 1.0 x 1 .0. La 
coppia di valori impostati come anchor ( > non è altro che un modo per definire la posizione dell'icona 
in relazione alla location del marker associato. Impostiamo il valore come nella seguente istruzione: 

final LatLng newLatLng = new LatLng (mCurrentLocation . getLatitude ( ) , 

mCurrentLocation . getLongitude ( ) ) ; 
final MarkerOptions markerOptions = new MarkerOptions ( ) ; 
markerOptions . position (newLatLng) . anchor (0 . Of, O.Of); 
mHereMarker = mGoogleMap . addMarker (markerOptions) ; 

Il risultato è mostrato nella Figura 14.16, ovvero la posizione del marker associato a unpinè nel 
punto (o, o) del sistema di riferimento corrispondente all'icona. 

Impostando invece nel modo seguente il valore a (1 , 1) si ottiene il risultato riportato nella Figura 
4.17: 

final LatLng newLatLng = new LatLng (mCurrentLocation . getLatitude () , 

mCurrentLocation . getLongitude ( ) ) ; 
final MarkerOptions markerOptions = new MarkerOptions () ; 
markerOptions . position (newLatLng) . anchor (1 . Of, l.Of); 
mHereMarker = mGoogleMap . addMarker (markerOptions) ; 
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Figura 14.16 La posizione corrente è in alto a sinistra rispetto all'icona. 
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Figura 14.17 La posizione corrente è in basso a destra rispetto all'icona. 

Da quanto detto capiamo come il valore di delàult sia dato dalla coppia (o , 5 f , ì , o f ), che si può 
ottenere come segue: 

final LatLng newLatLng = new LatLng (mCurrentLocation . getLatitude ( ) , 

mCurrentLocation . getLongitude ( ) ) ; 
final MarkerOptions markerOptions = new MarkerOptions () ; 
markerOptions . position (newLatLng) . anchor (0 . 5f , 1 . Of ) ; 
mHereMarker = mGoogleMap . addMarker (markerOptions) ; 

Indipendentemente dalla posizione dell'icona dato il valore dell' anchor point, vediamo come la 
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selezione del pin con un evento di clic non porti a niente. Proviamo quindi a impostare un valore per il 
titolo attraverso il metodo titie o nel seguente modo: 

final MarkerOptions markerOptions = new MarkerOptions () ; 

markerOptions . position (newLatLng) . anchor (0 . 5f , l.Of) .title("My Position"); 

mHereMarker = mGoogleMap . addMarker (markerOptions) ; 

per ottenere invece quello nella Figura 14.18. La presenza diuntitle è infatti condizione 
imprescindibile alla visualizzazione di un messaggio pop-up in corrispondenza della selezione del pin 
nella mappa. 
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Figura 14.18 Visualizzazione del title associato al marker. 

Se avessimo impostato anche il valore relativo allo snippet il risultato sarebbe stato quello della 
Figura 14.19. 
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Figura 14.19 Visualizzazione del title e dello snippet associati al marker. 

final MarkerOptions markerOptions = new MarkerOptions ( ) ; 
markerOptions . position (newLatLng) . anohor ( 0 . 5f , l.Of) 

.title("My Position") .snippet (" ["+ newLatLng . latitude + ", " 

+ newLatLng . longitude + " ] " ) ; 

mHereMarker = mGoogleMap . addMarker (markerOptions) ; 

Da osservare come il titolo rappresenti un'informazione necessaria per la visualizzazione del 
relativo pop-up. 

A questo punto vogliamo gestire due importanti lùnzionalità: 

• personalizzazione dell'icona del marker; 

• eventi associati al pop-up . 

Nel primo caso il metodo di riferimento è questo: 

public MarkerOptions icon (BitmapDescriptor icon) 

il quale prevede l'utilizzo di un oggetto di tipo bì tmapDe script or, il quale contiene le informazioni 
relative alle modifiche da apportare all'icona corrente. È interessante notare come non si dovrà mai 
creare in modo esplicito un'istanza di questa classe ma si dovranno invece sempre utilizzare metodi di 
Factory della classe bì tmapDescriptorFactory. Nel caso in cui volessimo modificare solamente il 
colore potremmo quindi creare l'oggetto bì tmapDe script or attraverso queste righe di codice: 

markerOptions . position (newLatLng) . anchor (0 . 5f , l.Of) 
.title ("My Position") 

. snippet ("[ "+ newLatLng . latitude + ", " + newLatLng . longitude + "]") 
. icon (BitmapDescriptorFactory 

. def aultMarker (BitmapDescriptorFactory . HUE_BLUE) ) ; 

nelle quali abbiamo evidenziato l'invocazione del seguente metodo: 

public static BitmapDescriptor def aultMarker ( float hue) 



il quale consente appunto di modificare il colore attraverso una serie di costanti che la stessa classe 
di Factory ci mette a disposizione. Nel nostro esempio abbiamo impostato ima tonalità vicina al 
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colore blue ottenuto il risultato nella Figura 14.20. 
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Figura 14.20 Personalizzazione del colore del marker. 



NOTA 



Il lettore avrà notato come il colore del marker non venga specificato attraverso le classiche 
componenti RGB ( reg, green e blue) ma attraverso quella che si chiama hue (la tonalità), che è 
rappresentata da un valore numerico compreso tra 0 e 360. Per dare un'idea del suo significato 
possiamo dire che un valore diverso di tonalità di un colore è quello che ci permette di dire che si 
tratta di un blu brillante, oppure rosa pastello o "di colore vivo". 

Una domanda che il lettore sicuramente si porrà è quella legata alla possibilità di utilizzare valori 
diversi da quelli specificati attraverso le relative costanti statiche della classe 
BitmapDescriptorFactory. Per verificare questa cosa chiediamo al lettore di ripetere un semplice 
esperimento di cui abbiamo visualizzato il risultato nella Figura 14.21. Si tratta della visualizzazione di 
tre marker per ciascuno di quali il colore differisce di quantità tali da non ricadere nei valori definiti 
attraverso le precedenti costanti 
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Figura 14.21 Utilizzo di valore diversi di tonalità (hue). 

Come possiamo notare, si hanno tre diverse gradazioni del colore con base blu, il che dimostra 
come sia possibile utilizzare un qualunque valore di hue compreso tra 0 e 360. 
NOTA 

Ricordiamo al lettore di testare la possibilità di spostare i marker attraverso un evento di drag dopo 
aver abilitato la relativa opzione in fase di creazione del marker o successivamente attraverso il 

metodo setDraggable ( ) . 

Se si volesse invece sostituire l'icona del marker, il metodo da utilizzare sarebbe icono, il cui 
parametro è sempre un oggetto di tipo bì tmapDescriptorFactory ; questo dispone di quattro diversi 
metodi per il caricamento dell'immagine a seconda della sua definizione all'interno dell'applicazione. 
Le sorgenti per l'icona sono le seguenti: 

• un oggetto di tipo Bitmap; 

• cartella degli asset; 

• da file; 

• da una risorsa. 

A queste azioni corrispondono, rispettivamente, questi metodi; 

public static BitmapDescriptor fromBitmap (Bitmap image) 

public static BitmapDescriptor fromAsset (String assetName) 

public static BitmapDescriptor fromFile (String fileName) 

public static BitmapDescriptor fromResource (int resourceld) 

Sono metodi abbastanza intuitivi e semplici da utilizzare. Nel caso in cui volessimo sostituire l'icona 
del marker con quella principale dell'applicazione basterebbe eseguire queste poche righe di codice: 

final MarkerOptions markerOptions = new MarkerOptions ( ) ; 
markerOptions . position (newLatLng) . anchor ( 0 . 5f , l.Of) 
.titleC'My Position 2") 

. snippet ( " [ "+ newLatLng . latitude + ", " + newLatLng . longitude + "]") 
. icon (BitmapDescriptorFactory . fromResource (R . drawable . ic_launcher ) ) ; 

mHereMarker = mGoogleMap . addMarker (markerOptions) ; 
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da cui il risultato della Figura 14.22 con l'icona dell'applicazione a fungere da marker. 




o 



o 



Figura 14.22 Personalizzazione dell'icona del marker. 

Anche qui, selezionando l'icona di un marker dotato di titolo, si ha la visualizzazione di quello che 
abbiamo chiamato pop-up ma che tecnicamente prende il nome di Info Window. Se aggiungiamo più 
marker possiamo notare come solamente un pop-up possa essere attivo in un particolare momento, 
per cui la selezione di un marker porterà alla chiusura del pop-up precedentemente visualizzato. Un 
aspetto interessante relativamente aWInf oWindow riguarda la possibilità di visualizzarla o nasconderla 
in modo programmatico attraverso i seguenti due metodi della classe Marker: 

public void showlnf oWindow ( ) 
public void hidelnf oWindow ( ) 

L'invocazione del metodo showlnf oWindow ( ) provocherà la chisura delle Info Window 
precedentemente aperte. 

Se non specificato diversamente la Figura 14.19, ci mostra come il titolo venga visualizzato in nero 
grassetto, mentre l'eventuale snippet viene visualizzato in grigio. Ogni framework che si rispetti è 
comunque caratterizzato dai propri punti di estensione che ne permettono la personalizzazione. Anche 
le Google Map API ci permettono quindi di personalizzare Ylnfo Window attraverso la creazione di 
implementazioni dell'interfaccia GoogieMap. infowindowAdapter, la quale precede la definizione delle 
seguenti due operazioni: 

public abstract View getlnf oContents (Marker marker) 
public abstract View getlnf oWindow (Marker marker) 

Prima di descrivere il significato di queste due operazioni è bene da subito sottolineare come 
l'implementazione di questa interfaccia sia solitamente ima sola, che viene poi assegnata alla 
GoogieMap attraverso il metodo 

public final void setlnf oWindowAdapter (GoogleMap . Inf oWindowAdapter adapter) 

Si tratta di un aspetto voluto anche alla luce del fatto che non si può visualizzare più di un'Info 
Window per mappa, per cui è possibile anche implementare logiche di riutilizzo delle view che si 
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andranno a creare, come vedremo nel nostro esempio. Notiamo poi come il marker di riferimento 
venga comunque passato come parametro delle due operazioni precedenti, che vengono invocate in 
un ordine ben preciso, consentendo di definire diversi livelli di personalizzazione. Il primo metodo 
invocato è infatti |etinf owindow ( ) , il quale potrà ritornare la view da visualizzare oppure nuli. Nel 
primo caso VInfoWindow corrisponderà a quanto ritornato, mentre nel secondo caso si sta 
informando il framework che si intende riciclare il contenitore di default ma modificarne eventualmente 
il contenuto attraverso l'implementazione del metodo getlnf oContents ( ) . Un valore di ritomo nuli 
starà quindi a indicare la volontà di utilizzare l'Info Window di default con il contenuto predefinito. In 
caso contrario verrà inserita la view creata nell'Info Window esistente. È comunque di fondamentale 
importanza sottolineare come la view che caratterizza un'Info Window non sia attiva ma sia 
equivalente a un'immagine. Questo significa che, nel caso in cui vi fossero dei pulsanti o altri elementi 
attivi, questi non avrebbero comunque alcun effetto. L'unico evento attivo sarà quello di clic sull'intera 
Info Window, come vedremo successivamente. 

Nel nostro esempio abbiamo aggiunto la seguente implementazione che possiamo utilizzare per fare 
alcuni esperimenti che ritornano nuli come valore di una o entrambe le operazioni. La più semplice, 
che lasciamo al lettore, riguarda il caso in cui entrambi i metodi ritornino il valore nuli, nel qual caso 
si avrebbe la visualizzazione deWInfo Window di default già vista nella Figura 14.19: 

private GoogleMap . Inf oWindowAdapter mCompletelnf oWindowAdapter = 
new GoogleMap . Inf oWindowAdapter ( ) { 

private View mViewContent ; 

class ContentHolder { 

private TextView tìtleView; 

private TextView snippetview; 

} 

SOverride 

public View getlnf oWindow (Marker marker) { 
ContentHolder holder = nuli; 
if (mViewContent == nuli) { 

mViewContent = getLayoutlnf later ( ) 

. inf late (R. layout . inf o_window_container, nuli) ; 
holder = new ContentHolder () ; 
holder . titleView = (TextView) mViewContent 
. f indViewByld (R. id. inf o_window_title) ; 
holder . snippetview = (TextView) mViewContent 
. f indViewByld (R. id. inf o_window_snippet ) ; 
mViewContent . setTag (holder) ; 
} else { 

holder = (ContentHolder) mViewContent . getTag () ; 

} 

// Mostriamo i dati 

holder .titleView . setText (marker . getTìtle ( ) ) ; 
holder . snippetview . setText (marker . getSnippet ( ) ) ; 
return mViewContent; 

} 

SOverride 

public View getlnf oContents (Marker marker) { 
ContentHolder holder = nuli; 
if (mViewContent == nuli) { 

mViewContent = getLayoutlnf later ( ) 

. inf late (R. layout . inf o_window_content, nuli) ; 
holder = new ContentHolder () ; 
holder . tìtleView = (TextView) mViewContent 
. f indViewByld (R. id. inf o_window_title) ; 
holder . snippetview = (TextView) mViewContent 
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. f indViewByld (R. id. inf o_window_snippet ) ; 
mViewContent . setTag (holder) ; 
} else { 

holder = (ContentHolder ) mViewContent . getTag () ; 

} 

// Mostriamo i dati 

holder . titleVìew . setText (marker . getTitle ( ) ) ; 
holder . snippetview . setText (marker . getSnippet () ) ; 
/ / Ritorniamo la view 
return nuli; 



Nel codice precedente è stato riutilizzato il pattern Holder che avevamo utilizzato per il riciclo delle 
celle di una Listview proprio perché in ogni momento può essere attiva al più una sola Info Window. 
Ricordiamo inoltre che solamente una delle due operazioni può ritornare un valore diverso da nuli. 
Nel codice sopra riportato il metodo fcetinf owindow ( ) ritorna una view che utilizza un layout 
personalizzato (in info_window_container .xml), che nel nostro caso ha semplicemente uno sfondo 
azzurro e due etichette per la visualizzazione di titolo e snippet. In questo caso il metodo 
getinfocontents o ritorna nuli e il risultato è quello nella Figura 14.23. 
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Figura 14.23 Personalizzazione dell'intera Info Window. 
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Qualora fosse il primo metodo a ritornare nuli e il secondo a ritornare il valore della variabile che 
abbiamo chiamato mViewContent, il risultato sarebbe quello nella Figura 14.24, dove è cambiato, 
rispetto alla versione standard, solamente il contenuto dell'Info Window ma non la sua forma 
rettangolare. 

ATTENZIONE 

Invitiamo il lettore a fare attenzione nel commentare il codice relativo a uno dei due metodi che poi 
ritornerà il valore nuli, per non incorrere in errori dovuti al fatto che abbiamo utilizzato la stessa view 
nella variabile mViewContent. Ricordiamo infatti che nel secondo caso il metodo getmfowindowo viene 
comunque invocato prima del metodo getmfocontentso. 
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Figura 14.24 Personalizzazione del solo contenuto dell'Info Window. 

Come abbiamo accennato, le view ritornate nei due casi sono completamente passive, ovvero 
vengono trattate come fossero semplicemente delle immagini Questo ci permette di affermare che si 
tratterà di view per la visualizzazione di informazioni e non di elementi attivi come pulsanti, caselle di 
testo o altri widget. Detto questo, il framework ci consente comunque di gestire alcuni eventi e 
precisamente: 

• clic sul marker; 
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• spostamento del marker; 

• eventi legati aWInfo Window. 

il tutto attraverso il solito meccanismo del Delegation Model basato sull'implementazione di 
opportuni listener. 

L'evento più semplice legato a un marker è quello di clic, il cui comportamento di delàult sappiamo 
essere la visualizzazione della corrispondente Info Window nel caso in cui sia presente un title. 

Se volessimo eseguire un'azione personalizzata in corrispondenza dell'evento di clic sarebbe 
sufficiente implementare l'interfaccia GoogieMap.onMarkerciickListener, la quale prevede la 
definizione dell'operazione 

public abstract boolean onMarkerClick (Marker marker) 

e quindi registrarla sulla GoogieMap attraverso il seguente metodo: 

public final void setOnMarkerClìckListener (GoogleMap . OnMarkerClickLìstener 

listener) 

Notiamo come il metodo dicallback contenga il riferimento al marker selezionato come parametro; 
inoltre abbiamo un valore di ritorno di tipo boolean il cui significato è tipico di questi metodi e 
permette di indicare ilframework se l'evento è da considerarsi consumato (true) oppure no (false). 
Se l'evento è consumato, il valore di ritorno sarà true e quindi l'Info Window non verrà visualizzata, 
a differenza del caso in cui il valore di ritorno fosse false. Il secondo tipo di evento è invece legato 
alla possibilità di spostare un marker attraverso un evento di long click seguito appunto da un 
trascinamento del dito. Ricordando che un marker non è draggabile per default, e che quindi è una 
feature che dovrà essere abilitata in modo esplicito, l'interfaccia da implementare si chiama 
GoogleMap. onMarkerDragListener e le relative operazioni saranno: 

public abstract void onMarkerDragStart (Marker marker) 
public abstract void onMarkerDrag (Marker marker) 
public abstract void onMarkerDragEnd (Marker marker) 

invocate rispettivamente in corrispondenza dell'attivazione, con long click, dell'evento, dell'azione 
effettiva di drag e quindi della sua fine. Il metodo per registrare questa implementazione nella mappa 
è: 

public final void setOnMarkerDragListener (GoogleMap . OnMarkerDragListener 

listener) 

Vediamo come anche qui venga comunque sempre passato il riferimento al marker sul quale 
l'evento è stato eseguito. Questa volta notiamo solamente come si tratti di operazioni che non hanno 
alcun tipo di ritorno. Come ultima cosa relativamente a questo evento, diciamo che è possibile 
ottenere la posizione di destinazione semplicemente invocando il seguente metodo sul marker ottenuto 
come parametro nel metodo onMarkerDragEnd o : 

public LatLng getPosition ( ) 

Infine si può gestire l'evento di selezione dell' InfoWindow attraverso l'implementazione 
dell'interfaccia GoogleMap. omnfowindowciickListener e precisamente dell'operazione 

public abstract void onlnf oWindowClick (Marker marker) 

il cui significato è ora evidente. Osserviamo solamente come anche qui il valore di ritorno sia voìd e 
non un boolean; non abbiamo infatti alcun problema di propagazione dell'evento. In questo caso il 
metodo di registrazione alla mappa è il seguente: 

public final void setOnlnf oWindowClickListener (GoogleMap 

. Onlnf oWindowClickListener listener) 
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Nella nostra applicazione abbiamo deciso di implementare quest'ultima interfaccia in modo tale 
che, in caso di selezione deWInfo Window, venga visualizzato l'indirizzo della posizione 
corrispondente in un Toast utilizzando una ulteriore feature che utilizza un servizio che prende il nome 
di Geocoder. È una funzione che necessita di un servizio lato server di cui è sempre bene verificare la 
disponibilità attraverso questo metodo statico della classe Geocoder: 

public static boolean isPresentO 

Una volta accertata la disponibilità del servizio lato server non facciamo altro che invocare il 
metodo 

public List<Address> getFromLocation (doublé latìtude, doublé longitude, 
int maxResults) 

il quale ritorna un elenco di possibili indirizzi che l'applicazione dovrà gestire. È un metodo che 
necessita delle coordinate della location e quindi il numero massimo di risultati accettati. Come è facile 
intuire si tratta di un metodo molto impegnativo che è quindi bene eseguire in un thread separato da 
quello della UI. Per questo motivo abbiamo inserito l'invocazione del metodo all'interno di un 
AsyncTask come nel seguente codice, a cui serve un API Level minimo pari a 9. Il codice relativo alla 
gestione dell'evento di selezione deWInfo Window è molto semplice e precisamente: 

private GoogleMap . Onlnf oWindowClickListener mlnf oWindowListener = 
new GoogleMap . Onlnf oWindowClickListener ( ) { 
SOverride 

public void onlnf oWindowClick (Marker marker) { 

// Eseguiamo AsyncTask passando le coordinate della posizione 
final LatLng markerPosition = marker . getPosition () ; 
final GeocoderAsyncTask geoCoderAsync = new GeocoderAsyncTask ( ) ; 
geoCoderAsync . execute (markerPosition . latitude, 
markerPosition. longitude) ; 

} 

}; 

Notiamo come, dopo aver ottenuto la posizione del marker associata aWInfo Window selezionata, 
si crei un'istanza dell' AsyncTask descritto dalla classe GeocoderAsyncTask per la determinazione del 
relativo indirizzo. Il codice che descrive il task è il seguente: 

private class GeocoderAsyncTask extends AsyncTask<Double, Void, Address> { 
@Override 

protected void onPostExecute (Address address) { 
super . onPostExecute (address ) ; 

// Qui abbiamo bisogno di mostrare l'indirizzo 
if (address != nuli) { 

final String addressStr = address . getLocality ( ) + " " + 

address . getPostalCode ( ) ; 
Toast .makeText (getApplicationContext ( ) , addressStr, 
Toast . LENGTH_SHORT) . show ( ) ; 

} else { 

Toast .makeText (getApplicationContext () , "Service not available 
or errori", Toast . LENGTH_SHORT) . show () ; 

} 

} 

SOverride 

protected Address doInBackground (Doublé .. . coordinates) { 
// Testiamo la presenza del Geocoder 
final boolean geoExists = Geocoder . isPresent () ; 
Address candidateAddress = nuli; 
if (geoExists) { 

final Geocoder geocoder = new Geocoder (getApplicationContext ()) ; 
try { 

final List<Address> addresses = 

geocoder . getFromLocation (coordinates [0] , 
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coordinates [1] , 1) ; 
if (addresses != nuli && addresses . size () != 0) { 
candidateAddress = addresses .get (0) ; 

} 

} catch (IOException e) { 
e .printStackTrace () ; 

} 

} 

return candidateAddress; 

} 

} 

Dopo aver verificato l'esistenza del servizio con il metodo statico Geocoder . isPresent ( ) abbiamo 
invocato il metodo getFromLocation o accontentandoci del primo indirizzo trovato, che poi abbiamo 
utilizzato per la visualizzazione attraverso un Toast. Il risultato, oscurato leggermente per motivi di 
privacy, è mostrato nella Figura 14.25. Osservando la classe Address del package android. location 
vediamo come le informazioni disponibili sarebbero molte di più di quelle da noi visualizzate nel Toast. 
Si tratta di informazioni che non sempre sono accurate, per cui sarà responsabilità della particolare 
applicazione quello di farne un utilizzo appropriato. 

Definizione della zona di alert 

Come descritto all'inizio del capitolo, la nostra applicazione dovrà permetterci di definire una 
regione nella mappa e quindi generare un qualche alert nel momento in cui la nostra posizione entrasse 
in tale regione. In questo paragrafo affronteremo il problema di definire questa regione, studiando tutti 
gli strumenti che il framework ci offre per disegnare sulla mappa. 
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Figura 14.25 Visualizzazione dell'indirizzo attraverso Geocoder. 



NOTA 

Come vedremo successivamente, le regioni che il sistema di Geofence sarà in grado di gestire 
sono circolari e quindi caratterizzate da una location e da un raggio che rappresenta la massima 
distanza dalla location stessa. In questo paragrafo vedremo inizialmente gli strumenti a 
disposizione per poi utilizzare quelli appropriati per la nostra specifica esigenza. 

Le API che il framework ci fornisce ci permettono di disegnare sulla mappa alcune forme 
geometriche e precisamente 

• insiemi di linee connesse tra loro per la rappresentazione di un percorso qualunque; 

• un poligono; 

• un cerchio. 

Questi vengono rappresentati rispettivamente dalle seguenti classi del package maps .model! 

• Polyline 

• Polygon 

• Circle 
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Si tratta di figure personalizzabili secondo degli attributi comuni, che sono: 

• colore e ampiezza del tratto; 

• colore del riempimento; 

• segmenti geodetici; 

• profondità; 

• visibilità. 

Vedremo tutto nei successivi esempi, iniziando da quello relativo alla polilinea, la quale viene creata 
e poi aggiunta alla mappa secondo un pattern che riprende quello utilizzato per i marker. Attraverso 
un oggetto di tipo xxxoptions si definiscono le caratteristiche relative al particolare oggetto, che 
quindi viene creato e aggiunto alla mappa attraverso un metodo del tipo addxxx ( > della classe 

GoogleMap. 

Iniziando dalla classe Poiyiine, sarà sufficiente creare un'istanza della classe PolylineOptions da 
utilizzare poi per la creazione di un'istanza dipoiyiine attraverso il metodo addPolyline ( ) . Essendo 
un insieme di segmenti, notiamo come si tratti principalmente dell'aggiunta delle location di alcuni punti 
le cui coordinate sono incapsulate all'interno di oggetto di tipo LatLng. Nel caso in cui il percorso 
fosse chiuso, il primo punto aggiunto coinciderebbe con l'ultimo. Nel nostro esempio abbiamo 
implementato il seguente metodo, il quale, se invocato attraverso il codice che qui è inizialmente 
commentato, porterà al risultato della Figura 14.26: 

private void drawPolyline ( ) { 

// Creiamo la PolylineOptions relativa alla posizione corrente 
final doublé step = 0.005; 

final doublé startLat = mCurrentLocation . getLatitude () ; 
final doublé startLon = mCurrentLocation . getLongitude () ; 
final PolylineOptions polylineOptions = new PolylineOptions ( ) 

.add(new LatLng (startLat, startLon)) 

.add(new LatLng ( startLat + step, startLon)) 

.add(new LatLng ( startLat + step, startLon + step)) 

.add(new LatLng (startLat, startLon + step)) 

.add(new LatLng (startLat, startLon)) 

. color (Color .RED) ; 
final Poiyiine newPolyline = mGoogleMap . addPolyline (polylineOptions ) ; 

} 
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Figura 14.26 Esempio di visualizzazione di una polilinea. 

Nel nostro esempio abbiamo semplicemente aggiunto un percorso chiuso utilizzando quattro valori 
di Location, ma avremmo potuto creare un insieme di segmenti più complesso. Nel nostro caso 
abbiamo infatti ottenuto lo stesso risultato che avremmo ottenuto nel caso di un poligono. In sintesi la 
differenza tra queste due forme consiste nel fatto che, mentre una polilinea può essere aperta, un 
poligono è necessariamente chiuso, per cui non occorre specificare l'ultimo punto come coincidente 
con il primo. Esso è inoltre caratterizzato da una superficie e non da un insieme di segmenti II 
seguente frammento di codice porta al risultato della Figura 14.27: 

private void drawPolygon ( ) { 

// Creiamo PolylineOptions relativa alla posizione corrente 
final doublé step = 0.005; 

final doublé startLat = mCurrentLocation . getLatitude () ; 
final doublé startLon = mCurrentLocation . getLongitude () ; 
final PolygonOptions polygonOptions = new PolygonOptions ( ) 

.add(new LatLng (startLat, startLon)) 

.add(new LatLng (startLat + step, startLon)) 

.add(new LatLng ( startLat + step, startLon + step)) 

.add(new LatLng (startLat, startLon + step)) 

. strokeColor (Color . BLUE) 

. strokeWidth (2 . Of ) 

. fillColor (Color. RED) ; 
final Polygon newPolygon = mGoogleMap . addPolygon (polygonOptions) ; 

} 

Come accennato, notiamo l'assenza dell'ultimo punto ma l'aggiunta delle informazioni che 
permettono la personalizzazione del colore di riempimento e del colore e relativo spessore del tratto 
del bordo. 
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Figura 14.27 Esempio di visualizzazione di un poligono. 

Le due immagini precedenti ci portano a una domanda legata alla possibilità di eliminare dalla 
regione delimitata da un poligono la parte definita attraverso una o più polilinee o altri poligoni. È 
un'operazione possibile attraverso questo metodo della classe PolygonOptions 

public PolygonOptions addHole ( Iterable<LatLng> points) 

il quale esclude dal poligono che si sta creando la regione delimitata dai punti passati come 
parametro attraverso un qualunque oggetto di tipo iterabie<LatLng>, che altro non è che un 
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qualunque oggetto in grado di fornire un iterator<LatLng> delle informazioni che ha al suo interno. 

Infine il framework ci mette a disposizione la classe circie, che ci permetterà di definire una 
regione circolare in termini di location del centro e distanza massima dallo stesso in metri Anche in 
questo caso abbiamo realizzato il seguente esempio, che produce il risultato nella Figura 14.28: 

private void drawCircle ( ) { 

// Creiamo CiroleOptions relativa alla posizione corrente 
final doublé centerLat = mCurrentLooation . getLatitude ( ) ; 
final doublé oenterLon = mCurrentLocation . getLongitude ( ) ; 
final CircleOptions circleOptions = new CircleOptions () 

. center (new LatLng (centerLat , centerLon) ) 

.radius (250) 

. strokeColor (Color . BLUE) 
. strokeWidth (2 . Of ) 
. f illColor (Color . YELLOW) ; 
final Circle newCircle = mGoogleMap . addCircle (circleOptions) ; 

} 

Il centro viene specificato attraverso il metodo center ( ) , mentre il colore del bordo e del 
riempimento si definiscono rispettivamente attraverso i metodi strokeColor ( ) e Itrokewidth ( ) 
sopra evidenziati 




Figura 14.28 Esempio di visualizzazione di un cerchio. 

Negli esempi abbiamo impostato valori di personalizzazione diversi al fine di dare ima 
dimostrazione significativa. Sono comunque configurazioni molto semplici a parte quello che si 
chiama segmento Geodetico. 

NOTA 

Si tratta di un'impostazione che ha senso solamente nel caso di poiyiìne e poiygon e consente di 
definire la modalità di renderizzazione. La superficie della Terra è quasi sferica, mentre i percorsi 
sono dritti. Serve quindi un meccanismo per configurare la modalità con cui un segmento dritto può 
essere renderizzato su una superficie rotonda. 

A questi punto non ci resta che trovare un modo che ci permetta di definire una zona all'interno 
della mappa. Per farlo abbiamo utilizzato l'evento di long click, che porta alla visualizzazione di ima 
finetra di dialogo per rinserimento del raggio relativo alla regione da definire. Nel nostro esempio 
gestiremo una sola zona, per cui la definizione di ima nuova regione porterà alla cancellazione della 
precedente. Qui l'evento da gestire è quello che prevede l'implementazione dell'interfaccia 
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GoogleMap.OnMapLongClickListener e quindi del metodo: 

public abstract void onMapLongClick (LatLng point) 

Ricordiamo che dovremo poi registrare l'implementazione nella GoogieMap attraverso il seguente 
metodo: 

public final void setOnMapLongClickListener (GoogleMap . OnMapLongClickListener 

listener ) 

Allo stesso modo è possibile gestire l'evento di clic sulla mappa attarverso la creazione di 
un'implementazione dell' interfaccia GoogleMap. onMapciickListener e quindi dell'operazione: 

public abstract void onMapClick (LatLng point) 

che possiamo poi impostare attraverso questo metodo della classe GoogleMap: 

public final void setOnMapClickListener (GoogleMap . OnMapClickListener listener) 

Nel nostro caso abbiamo semplicemente fatto in modo di aggiungere un cerchio centrato nel punto 
di long click per poi eventualmente eliminarlo nel caso in cui lo si selezionasse con un evento di clic. 
L'implementazione del listener associato all'evento di long click è il seguente: 

private GoogleMap . OnMapLongClickListener mOnMapLongClickListener = 
new GoogleMap . OnMapLongClickListener ( ) { 
@Override 

public void onMapLongClick (LatLng latLng) { 

//Se esiste un altro Circle lo eliminiamo 
if (mCurrentCircle != nuli) { 
mCurrentCircle . remove ( ) ; 

} 

// Creiamo un nuovo Circle 

final CircleOptions circleOptions = new CircleOptions ( ) 
. center (latLng) 
.radius (300) 

. strokeColor (Color . BLUE) 
. strokeWidth (2 . Of ) 

.fillColor(Color.parseColor("#66FF0000") ) ; 
mCurrentCircle = mGoogleMap . addCircle (circleOptions) ; 

} 

}; 

Nel caso fosse già presente un oggetto cìrcie associato alla variabile d'istanza mCurrentCircle, 
allora ci preoccupiamo di eliminarlo per poi creare la nuova istanza con le istruzioni viste in 
precedenza. La gestione dell'evento di clic avviene invece attraverso la seguente implementazione: 

private GoogleMap . OnMapClickListener mOnMapClickListener = 
new GoogleMap . OnMapClickListener ( ) { 
SOverride 

public void onMapClick (LatLng latLng) { 
if (mCurrentCircle != nuli) { 

// Dobbiamo creare la distanza usando l'oggetto LatLng 
final LatLng centerPoìnt = mCurrentCircle . getCenter () ; 
final LatLng clickedPoìnt = latLng; 
final doublé dìstance = 

Math . abs (WakeMeUtility . getDìstance (centerPoint, 
clickedPoint ) ) ; 
if (distance < mCurrentCircle . getRadius () ) { 
// Lo eliminiamo 
mCurrentCircle . remove ( ) ; 
mCurrentCircle = nuli; 

} 

} 

} 

}; 

In questa fase notiamo la presenza dell'invocazione di un metodo di utilità per il calcolo della 
distanza tra due oggetti di tipo LatLng che abbiamo implementato in questo metodo di utilità: 
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public static doublé getDistance (final LatLng first, final LatLng second) { 
doublé dLat = Math . toRadians (second . latitude-f irst . latitude) ; 
doublé dLon = Math . toRadians (second. longitude - first . longitude) ; 
doublé a = Math . sin (dLat/2 ) * Math . sin (dLat/2 ) + 

Math . cos (Math . toRadians (first . latitude) ) * 

Math .cos (Math . toRadians (second . latitude) ) * 

Math. sin (dLon/2) * Math . sin (dLon/2 ) ; 
doublé c = 2 * Math . asìn (Math . sqrt (a) ) ; 
return 6366000 * c; 

} 

Il lettore potrà rilevare come un evento di long click provochi l'aggiunta di un cerchio, e come un 
evento di clic all'interno del cerchio creato ne determini l'eliminazione. 
NOTA 

Nel nostro esempio abbiamo lasciato costante la dimensione del raggio creato ma si può creare un 
meccanismo per editarne le dimensioni. Notiamo solamente come l'evento di trascinamento non ci 
venga in aiuto provocando, nella mappa, un'operazione di panoramica. 

Siamo ora pronti ad affrontare una nuova feature dei Google Play Services dedicati alle mappe 
opwero la possibilità di eseguire applicazioni nel modo più semplice e veloce, come vedremo nel 
prossimo paragrafo. 

Creazione e gestione di Geofence 

Nel paragrafo precedente abbiamo creato tre tipologie diverse di figure da disegnare su una mappa 
tra cui quella circolare, cheè caratterizzata da una location per il centro e da una distanza, in metri, per 
il raggio. A tal proposito abbiamo gestito l'evento di long click per l'aggiunta di un cerchio nella 
mappa e di un clic normale per la corrispondente rimozione. Le stesse informazioni che caratterizzano 
un cerchio sono in grado di caratterizzare un altro componente che prende il nome di Geofence, che 
definisce, per un certo periodo di tempo, una particolare zona della mappa per la quale il 
LocatìonManager può generare degli eventi Sono gli eventi relativi all'ingresso o all'uscita del 
dispositivo dalle zone definite. 

Il primo passo da percorrere nell' utilizzo di queste API consiste nella dichiarazione del seguente 
permesso, se non già presente, all'interno del file di configurazione AndroìdManif est . xml. 

<uses-permission android: name="android.permission . ACCESS_FINE_LOCATION"/> 

Questa definizione sta a indicare come il servizio necessiti di una buona accuratezza del segnale e 
quindi dell'utilizzo del GPS o di altri sistemi di precisione. 

Ogni Geofence è caratterizzato da un'istanza dell'omonima classe del package 

com. google, android. gms . location per la quale SÌ utilizza un Oggetto di tipo Geofence . Builder, 

aspetto che ormai non ci sorprende più. In particolare un Geofence è caratterizzato dalle seguenti 
informazioni; 

• posizione del centro e dimensione del raggio; 

• expiration time; 

• transition type; 

• geofence id. 

Le prime informazioni sono le stesse descritte in precedenza e che abbiamo utilizzato per la 
definizione di un oggetto cìrcie. A queste è stata aggiunta la possibilità di associare un tempo di 
scadenza oltre il quale il Geofence viene eliminato e quindi non si avrà più alcuna notifica o evento. Si 
tratta di un'informazione che dipende dalla natura dell'oggetto rappresentato. Nel caso della propria 
casa si dovrà creare, per esempio, un Geofence senza expiration time, a differenza di quello che 
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può rappresentare un punto di passaggio durante un viaggio. L'applicazione potrebbe decidere di 
eliminare il Geofence non appena l'utente vi entra. 

L'attributo relativo al transition type è quello che ci permette di dire se siamo interessati agli eventi 
di ingresso (entry) nell'area di un Geofence, agli eventi di uscita (exit) o a entrambi 

Infine un geofence id è semplicemente una String che caratterizza un Geofence e che quindi può 
essere utilizzata nell'applicazione per ottenerne un riferimento. Per gestire la funzionalità richiesta 
occorre implementare alcuni componenti di cui ormai conosciamo la natura sapendo come gestirli al 
meglio. Possiamo scomporre questa funzionalità della nostra applicazione in due parti: la prima di 
avvio del servizio e la seconda di gestione delle eventuli notifiche. Come possiamo vedere nel nostro 
esempio, la prima è stata implementata attraverso le prossime righe di codice, che eseguiremo in 
corrispondenza della creazione di un Geofence attraverso un evento di long click descritto in 
precedenza: 

Geofence . Builder fenceBuilder = new Geofence . Builder ( ) 

. setCircularRegion (latLng. latitude, latLng. longitude, DEFAULT_RADIUS ) 
. setExpirationDuration (Geofence .NEVER_EXPIRE) 
. setRequestld (GEOFENCE_REQUEST_ID) 

. setTransitionTypes (Geofence . GEOFENCE_TRANSITION_ENTER | 
Geofence . GEOFENCE_TRANSITION_EXIT) ; 
// Creiamo il Pendìnglntent da lanciare quando occorre l'evento 
final Intent fencelntent = new Intent (getApplicationContext () , 

GeofenceService . class) ; 
final Pendinglntent f encePendinglntent = 

Pendinglntent . get Servi ce (getApplicationContext (), 0, fencelntent, 

Pendinglntent .FLAG_UPDATE_CURRENT) ; 
mCurrentGeofences.add(fenceBuilder.build() ) ; 
// Aggiungiamo il Geofence al LocationManager 

mLocationClient . addGeofences (mCurrentGeof ences , f encePendinglntent , 
mOnAddGeofencesResultListener) ; 

Il primo passo consiste nella creazione dell'istanza di Geofence a partire dal relativo Builder. A 
questo punto abbiamo utilizzato il metodo addGeofences o della classe Locationciient, il quale 
necessita di tre importanti parametri II primo è una lista dei Geofence che dobbiamo gestire. Nel 
nostro caso abbiamo un unico Geofence per cui in precedenza abbiamo aggiunto l'elemento alla lista. 
Come è facile intuire, è un servizio di notifica, che quindi potrà avvenire anche quando l'applicazione 
non è in esecuzione. Per questo motivo serve un componente in grado di essere eseguito in 
bakground, da cuiunservice che abbiamo implementato nella classe GeofenceService. Si tratta di un 
Intent Servi ce che, come vedremo tra poco, ci permetterà di ricevere delle notifiche relativamente 
agli eventi a cui ci siamo registrati in fase di creazione del Geofence. 

Attraverso le costanti geofence_transition_enter e geofence_transition_exit della classe 
Geofence, abbiamo informato il LocationManager di essere interessati sia agli eventi di ingresso nella 
zona sia di uscita dalla stessa. Il terzo parametro è invece un'implementazione dell'interfaccia 
Locatìonciient.onAddGeofencesResuitListener, che ci consente diconoscere lo stato del servizio 
di Geofence. Nel nostro caso si tratta di un'implementazione al momento vuota che il lettore potrà 
utilizzare per i propri esperimenti. 

Se tutto va per il meglio il nostro LocationManager si preoccuperà di monitorare gli spostamenti 
dell'utente fino a lanciare il nostro intent per l'attivazione del servizio descritto dalla classe 
GeofenceService che abbiamo implementato come segue: 

public class GeofenceService extends IntentServìce { 

private static final String TAG_LOG = GeofenceService . class . getName () ; 
public GeofenceService ( ) { 
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super ( "Geof enceService" ) ; 

} 

SOverride 

protected void onHandlelntent (Intent intent) { 

// Inizialmente cerchiamo un errore. Nel caso mostriamo un messaggio di errore 
if (LocatìonClient . hasError ( intent ) ) { 
// Prendiamo il codice dell'errore 

final ìnt errorCode = LocationClient . getErrorCode ( intent ) ; 
// Mostriamo il messaggio d'errore 

Log . e (TAG_LOG, "Geofence Service got an error with code:" + 
Integer . toString (errorCode) ) ; 

} else { 

// Se tutto è corretto prendiamo le informazioni a proposito 
// del transactionld dell'evento 
final int transactionld = 

LocationClient . getGeof enceTransition (intent ) ; 
ìf (transactionld == Geof enee . GEOFENCE_TRANSITION_ENTER | | 

transactionld == Geof enee . GEOFENCE_TRANSITION_EXIT) { 
// In questo caso il nostro transactionld 
List<Geof ence> receivedGeof ences = 

LocationClient . getTriggeringGeof ences (intent ) ; 
// Qui possiamo fare ciò che vogliamo con ì dati ricevuti 
for (Geofence geofence : receivedGeof ences ) { 

Log . d (TAG_LOG, "Geofence triggeredwith id " + 
geofence . getRequestld ( ) ) ; 

} 

// Elaborazioni successive 
} else { 

Log . e (TAG_LOG, "Check your code!! No transactionld into the 
received Intent"); 

} 

} 

} 

} 

Dopo aver controllato l'assenza di eventuali errori, è stato utilizzato il metodo 
getTriggeringGeof ences ( ) della classe LocationClient per ottenere gli identificatori dei Geofence 
che hanno generato la notifica da cui eseguire le elaborazioni del caso. 

L'ultimo passaggio a questo punto riguarda l'eliminazione del Geofence dall'elenco di quelli che 
devono essere monitorati in corrispondenza della loro cancellazione attraverso evento di clic. Per 
tarlo abbiamo utilizzato le istruzioni 

final Stringi] geoFenceToRemove = new Stringi] { GEOFENCE_REQUEST_ID } ; 
mLocationClìent . removeGeof ences (Arrays . asList (geoFenceToRemove) , 
mOnRemoveGeofencesResultListener ) ; 

dove l'oggetto evidenziato è un'implementazione dell'interfaccia LocationClient . 
onRemoveGeofencesResuitListener che ci permette di ottenere dei callback per monitorare l'esito 
dell'operazione di cancellazione. Oltre al metodo per la rimozione di un Geofence attraverso il 
corrispondente transaction id notiamo anche la presenza del seguente 

public void removeGeof ences (Pendinglntent pendinglntent , 

LocationClient . OnRemoveGeof encesResultListener listener) 

il quale utilizza invece il riferimento al Pendinglntent associato. Invitiamo il lettore a rileggere le 
nostre considerazioni in relazione al confronto tra oggetti di questo tipo. Infine è bene ricordarsi di 
cancellare il monitoraggio dell'eventuale Geofence attivo anche qualora se ne crei un altro attraverso 
l'evento di long click. 

A questo punto non ci resta che invitare il lettore di armarsi di scarpe da tennis e verificare il 
funzionamento dell'applicazione definendo delle zone nella mappa e quindi muovendosi fuori e dentro 
i vari cerchi 
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Utilizzare il servizio di activity recognition 

Nel paragrafo precedente abbiamo visto come definire delle regioni dette Geofence e ricevere 
delle notifiche da parte del LocationClient m corrispondenza dell'ingresso e dell'uscita dalle stesse. 
Abbiamo utilizzato un pattern abbastanza classico nei Google Play Services che utilizzeremo anche 
in corrispondenza dell' activity recognition. Si tratta di un meccanismo in grado di capire la qualità 
dello spostamento dell'utente, ovvero se lo stesso sta camminando, si sta muovendo a piedi, corre o 
è in auto. Anche stavolta iniziamo dalla necessità di un permesso, ovvero: 

<uses-permission 

android: name="com. google . android. gms . permission . ACTIVITY_RECOGNITION" /> 

che andiamo quindi ad aggiungere a quelli esistenti nelpAndroidManif est . xml. 
NOTA 

A questo proposito è interessante notare come si tratti di un servizio che non necessita dei 
permessi relativi alla location (access_coarse_location o access_fine_location) visti in precedenza. 

Il passo successivo consiste nella definizione di alcune costanti relative alle frequenze di 
aggiornamento e di due variabili d'istanza relative al p endinglntent, che assoceremo agli update, e a 
un altro oggetto di tipo AotivityRecognitionClient che rappresenta lo strumento a nostra 
disposizione per questo tipo diservizio. Sono riferimenti che inizializzeremo nel metodo oncreate o 
della nostra activity nel seguente modo: 

dOverride 

protected void onCreate (Bundle savedlnstanceState) { 
super . onCreate (savedlnstanceState) ; 
setContentView (R. layout . activity_sìngle_f ragment ) ; 
// Otteniamo SharedPref erences 

mMapPref = Pref erenceManager . getDef aultSharedPref erences (this ) ; 
// Creiamo LocationClient passando il riferimento al callback 
// delle implementazioni dell'interfaccia 

mLocationClient = new LocationClient (this, mConnectionCallbacks , 

mOnConnectionFailedLìstener ) ; 
// Inizializziamo le variabili Activity Recognition 
mActivityRecognitionClient = 

new ActivityRecognitionClient (this, mConnectionCallbacks, 
mOnConnectionFailedListener) ; 
// Creiamo 1 ' intent per il service che riceverà le informazioni 
// Activity recognition 

final Intent activityRecognitionlntent = new Intent (this, 

ActivityRecognitionService . class) ; 
mActivityRecognitionPendinglntent = Pendinglntent . getService (this , 0, 

activityRecognitionlntent, Pendinglntent . FLAG_UPDATE_CURRENT) ; 

} 

In questo codice notiamo che i parametri utilizzati in fase di creazione 
dell' ActivityRecognitionClient sono gli stessi utilizzati nella creazione del LocationClient. Il passo 
successivo consiste nell' avviare il servizio attraverso la seguente istruzione: 

mActivityRecognitionClient . connect () ; 

che possiamo aggiungere all'implementazione del metodo onstart o dell' activity. Vediamo poi 
come P intent associato al p endinglntent relativo alle notifiche fàccia riferimento a Un IntentService 
descritto dalla classe ActivityRecognitionService. Per quello che riguarda l'avvio del sevizio 
dobbiamo però eseguire le prossime operazioni nel metodo onconnected ( ) di notifica dell'avvenuta 
connessione con i servizi di Google Play: 

mActivityRecognitionClient . requestActivityUpdates ( 

DETECTION_INTERVAL_MILLISECONDS , mAct ivityRecognit ionPendìnglntent ) ; 
mActivityRecognitionClient . disconnect ( ) ; 

L'ultimo passo riguarda la descrizione del nostro servizio, che non dovrà fàre altro che richiedere al 

636 



nostro ActivityRecognitionciient le informazioni volute. Nel nostro caso abbiamo implementato la 

classe ActivityRecognitionService COme Segue: 

public class ActivityRecognitionService extends IntentService { 

public ActivityRecognitionService ( ) { 

super ( "ActivityRecognitionService" ) ; 

} 

SOverride 

protected void onHandlelntent ( Intent intent) { 

// Inizialmente verifichiamo che ActivityRecognition abbia buoni risultati 
if (ActivityRecognitionResult .hasResult (intent) ) { 

// Prendiamo le informazioni dall' intent ricevuto 
ActivityRecognitionResult result = 

ActivityRecognitionResult. extractResult (intent) ; 
// Abbiamo anche informazioni sull'accuratezza dei dati 
DetectedActivity mostProbableActivity = 

result . getMostProbableActivity ( ) ; 
int confidence = mostProbableActivity . getConf idence () ; 
int activityType = mostProbableActivity . getType () ; 
String activityName = getNameFromType (activityType) ; 
// Altre cose da fare 

Log.i (TAG_LOG, "NEW ACTIVITY RECOGNISED : " + activityName); 

} 

} 

private String getNameFromType (int activityType) { 
switch (activityType) { 

case DetectedActivity . IN_VEHICLE : 

return "in_vehicle" ; 
case DetectedActivity. ON_BICYCLE: 

return "on_bicycle" ; 
case DetectedActivity .ON_FOOT: 

return "on_foot"; 
case DetectedActivity . STILL : 

return "stili"; 
case DetectedActivity .UNKNOWN: 

return "unknown"; 
case DetectedActivity .TILTING: 

return "tiltìng"; 

} 

return "unknown"; 

} 

} 

Notiamo come sia possibile verificare la presenza di informazioni e quindi acquisirle attraverso i 
metodi della classe ActivityRecognitionResult. Si tratta diuna funzionalità che si può rivelare molto 
utile specialmente in quella categoria di applicazioni legate allo sport oppure al consumo di calorie per 
una dieta. 

Conclusioni 

In questo ultimo e impegnativo capitolo abbiamo esaminato nel dettaglio tutti gli strumenti che la 
piattaforma Android ci mette a disposizione per la gestione della location e l'utilizzo delle mappe. 
Come pretesto di tutto ciò abbiamo realizzato un approccio di applicazione, la quale ci ha permesso 
di descrivere come i Google Play Services possano essere installati in Android Studio attraverso 
un'opportuna configurazione di Gradle. Il capitolo si è concluso con una veloce panoramica su un 
paio di servizi interessanti che sono stati presentati all'ultima Google IO (2013), ovvero la gestione 
dei Geofence e quella che si chiama activity recognition. 
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